| Justification: > The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information. > The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support. Personally I don't really buy this argument. I don't think the web sites that most people visit (especially highly-sensitive ones like for e-mail, financial stuff, a good portion of shopping) change or become "less trustworthy" that quickly. |
| |
| ▲ | throw0101a 4 days ago | parent | next [-] | | Okay, the key is compromised: that means they can MITM the trust relationship. But with modern algorithms you have forward security, so even if you've sniffed/captured the traffic it doesn't help. And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry. | | |
| ▲ | gruez 4 days ago | parent [-] | | >And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry. By that logic, we don't really need certificates, just TOFU. | | |
| ▲ | throw0101d 4 days ago | parent [-] | | > By that logic, we don't really need certificates, just TOFU. It works fairly well for SSH, but that tends to be a more technical audience. But doing a "Always trust" or "Always accept" are valid options in many cases (often for internal apps). | | |
| ▲ | tptacek 4 days ago | parent [-] | | It does not work well for SSH. We just don't care about how badly it works. | | |
| ▲ | throw0101d 4 days ago | parent [-] | | > It does not work well for SSH. We just don't care about how badly it works. How "should" it work? Is there a known-better way? | | |
| ▲ | tptacek 4 days ago | parent [-] | | Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI). | | |
| ▲ | throw0101d 4 days ago | parent [-] | | > Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI). I am aware of them. As someone in the academic sphere, with researchers SSHing into (e.g.) HPC clusters, this solves nothing for me from the perspective of clients trusting servers. Perhaps it's useful in a corporate environment where the deployment/MDM can place the CA in the appropriate place, but not with BYOD. Issuing CAs to users, especially if they expire is another thing. From a UX perspective, we can tie password credentials to things like on-site Wifi and web site access (e.g., support wiki). So SSH certs certainly have use-cases, and I'm happy they work for people, but TOFU is still the most useful in the waters I swim in. | | |
| ▲ | tptacek 4 days ago | parent [-] | | I don't know what to tell you. The problem with TOFU is obvious: the FU. The FU happens more often than people think it does (every time you log in from a new or reprovisioned workstation) and you're vulnerable every time. I don't really care what you do for SSH (we use certificates) but this is not a workable model for TLS, where FUs are the norm. | | |
| ▲ | throw0101d 4 days ago | parent [-] | | > I don't really care what you do for SSH (we use certificates) but this is not a workable model for TLS, where FUs are the norm. It was suggested by someone else: I commented TOFU works for SSH, but is probably not as useful for web-y stuff (except for maybe small in-house stuff). Personally I'm somewhat sad that opportunistic encryption for the web never really took off: if folks connect on 80, redirect to 443 if you have certs 'properly' set up, but even if not do an "Upgrade" or something to move to HTTPS. Don't necessary indicate things are "secure" (with the little icon), but scramble the bits anyway: no false sense of security, but make it harder for tapping glass in bulk. |
|
|
|
|
|
|
|
| |
| ▲ | xurukefi 3 days ago | parent | prev [-] | | Nobody forces you to change your key for renewals. |
|
