7 ms·

What's the end game here? I agree with the dissent. Why not make it 30 seconds? Once we cross the threshold of "I absolutely have to automate everything or it'

What's the end game here? I agree with the dissent. Why not make it 30 seconds? Once we cross the threshold of "I absolutely have to automate everything or it's not viable to use TLS anymore", why do we care about providing anything beyond ~48 hours? I am willing to bet money this threshold will never be crossed. This feels like much more of an ideological mission than a practical one, unless I've missed some monetary/power advantage to forcing everyone to play musical chairs with their entire infra once a month...

woodruffw 2y ago
The "end game" is mentioned explicitly in the article: > 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. Shorter-lived certificates make OCSP and other revocation mechanisms less of a load-bearing component within the Web PKI. This is a good thing, since neither CAs nor browsers have managed to make timely revocation methods scale well. (I don't think there's any monetary or power advantage to doing this. The reason to do it is because shorter lifetimes make it harder for server operators to normalize deviant certificate operation practices. The reasoning there is the same as with backups or any other period operational task: critical processes must be continually tested and evaluated for correctness.)
- sitkack 2y ago
  Don't lower cert times also get people to trust certs that were created just for their session to MITM them? That is the next step in nation state tapping of the internet.
  - ezfe 2y ago
    lol no? lower cert times still extend the root certificates that are already trusted. It is not a noticeable thing when browsing the web as a user. A MITM cert would need to be manually trusted, which is a completely different thing.
    - Lammy 2y ago
      I think their point is that a hypothetical connection-specific cert would make it difficult/impossible to compare your cert with anybody else to be able to find out that it happened. A CA could be backdoored but only “tapped” for some high-value target to diminish the chance of burning the access.
      - roblabla 2y ago
        Well, the cert can still be compared to what's in the CT Log for this purpose.
      - sitkack 2y ago
        Yes, precisely.
      - woodruffw 2y ago
        > I think their point is that a hypothetical connection-specific cert would make it difficult/impossible to compare your cert with anybody else to be able to find out that it happened. This is already the case; CT doesn't rely on your specific served cert being comparable with others, but all certs for a domain being monitorable and auditable. (This does, however, point to a current problem: more companies should be monitoring CT than are currently.)
  - woodruffw 2y ago
    I don't see why it would; the same basic requirements around CT apply regardless of certificate longevity. Any CA caught enabling this kind of MITM would be subject to expedient removal from browser root programs, but with the added benefit that their malfeasance would be self-healing over a much shorter period than was traditionally allowed.
fs111 2y ago
Load on the underlying infrastructure is a concern. The signing keys are all in HSMs and don't scale infinitely.
- bob1029 2y ago
  How does cycling out certificates more frequently reduce the load on HSMs?
  - timmytokyo 2y ago
    It's all relative. A 47-day cycle increases the load, but a 48-hour cycle would increase it substantially more.
  - woodruffw 2y ago
    Much of the HSM load within a CA is OCSP signing, not subscriber cert issuance.
timewizard 2y ago
If the service becomes unavailable for 48 straight hours then every certificate expires and nothing works. You probably want a little more room for catastrophic infrastructure problems.
notatoad 2y ago
>unless I've missed some monetary/power advantage the power dynamic here is that the CAs have a "too big to fail" inertia, where they can do bad things without consequence because revoking their trust causes too much inconvenience for too many people. shortening expiry timeframes to the point where all their certificates are always going to expire soon anyways reduces the harm that any one CA can do by offering bad certs. it might be inconvenient for you to switch your systems to accomodate shorter expiries, but it's better to confront that inconvenience up front than for it to be in response to a security incident.
mcpherrinm 2y ago
I'm on the team at Let's Encrypt that runs our CA, and would say I've spent a lot of time thinking about the tradeoffs here. Let's Encrypt has always self-imposed a 90 day limit, though of course with this ballot passing we will now have to reduce that under 47 days in the future. Shorter lifetimes have several advantages: 1. Reduced pressure on the revocation system. For example, if a domain changes hands, then any previous certificates spend less time in the revoked state. That makes CRLs smaller, a win for everyone involved. 2. Reduced risk for certificates which aren't revoked but should have been, perhaps because a domain holder didn't know that a previous holder of that domain had it, or an attack of any sort that led to a certificate being issued that wasn't desired. 3. For fully short-lived certs (under 7 days), many user-agents don't do revocation checks at all, because that's a similar timeline to our existing revocation technology taking effect. This is a performance win for websites/user-agents. While we advocate for full certificate automation, I recognize there are cases where that's not so easy, and doing a monthly renewal may be much more tractable. Going to shorter than a few days is a reliability and scale risk. One of the biggest issues with scale today is that Certificate Transparency logs, while providing great visibility into what certs exist (see points 1 and 2), will have to scale up significantly as lifetimes are cut. Why is this happening now, though? I can't speak for everyone, and this is only my own opinion on what I'm observing, but: One big industry problem that's been going on for the last year or two is that CAs have found themselves in situations where they need to revoke certificates because of issues with those certificates, but customers aren't able to respond on an appropriate timeline. So the big motivation for a lot of the parties here is to get these timelines down and really prove a push towards automation.
- efortis 2y ago
  4. Encrypted traffic hoarders would have to break more certs.
  - throwaway2037 2y ago
    This one? https://en.wikipedia.org/wiki/Utah_Data_Center https://en.wikipedia.org/wiki/Utah_Data_Center
- 2y ago
michaelt 2y ago
> Once we cross the threshold of "I absolutely have to automate everything or it's not viable to use TLS anymore", why do we care about providing anything beyond ~48 hours? Well you see, they also want to be able to break your automation. For example, maybe your automation generates a 1024 bit RSA certificate, and they've decided that 2048 bit certificates are the new minimum. That means your automation stops working until you fix it. Doing this with 2-day expiry would be unpopular as the weekend is 2 days long and a lot of people in tech only work 5 days a week.
karlgkk 2y ago
> Why not make it 30 seconds? This is a ridiculous straw man. > 48 hours. I am willing to bet money this threshold will never be crossed. That's because it won't be crossed and nobody serious thinks it should. Short certs are better, but there are trade-offs. For example, if cert infra goes down over the weekend, it would really suck. TBH, from a security perspective, something in the range of a couple of minutes would be ideal, but that runs up against practical reasons - cert transparency logs and other logging would need to be substantially scaled up - for the sake of everyone on-call, you really don't want anything shorter than a reasonable amount of time for a human to respond - this would cause issues with some HTTP3 performance enhancing features - thousands of servers hitting a CA creates load that outweighs the benefit of ultra short certs (which have diminishing returns once you're under a few days, anyways) > This feels like much more of an ideological mission than a practical one There are numerous practical reasons, as mentioned here by many other people. Resisting this without good cause, like you have, is more ideological at this point.

woodruffw 2y ago

The "end game" is mentioned explicitly in the article: > 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. Shorter-lived certificates make OCSP and other revocation mechanisms less of a load-bearing component within the Web PKI. This is a good thing, since neither CAs nor browsers have managed to make timely revocation methods scale well. (I don't think there's any monetary or power advantage to doing this. The reason to do it is because shorter lifetimes make it harder for server operators to normalize deviant certificate operation practices. The reasoning there is the same as with backups or any other period operational task: critical processes must be continually tested and evaluated for correctness.)

sitkack 2y ago
Don't lower cert times also get people to trust certs that were created just for their session to MITM them? That is the next step in nation state tapping of the internet.
- ezfe 2y ago
  lol no? lower cert times still extend the root certificates that are already trusted. It is not a noticeable thing when browsing the web as a user. A MITM cert would need to be manually trusted, which is a completely different thing.
  - Lammy 2y ago
    I think their point is that a hypothetical connection-specific cert would make it difficult/impossible to compare your cert with anybody else to be able to find out that it happened. A CA could be backdoored but only “tapped” for some high-value target to diminish the chance of burning the access.
    - roblabla 2y ago
      Well, the cert can still be compared to what's in the CT Log for this purpose.
    - sitkack 2y ago
      Yes, precisely.
    - woodruffw 2y ago
      > I think their point is that a hypothetical connection-specific cert would make it difficult/impossible to compare your cert with anybody else to be able to find out that it happened. This is already the case; CT doesn't rely on your specific served cert being comparable with others, but all certs for a domain being monitorable and auditable. (This does, however, point to a current problem: more companies should be monitoring CT than are currently.)
- woodruffw 2y ago
  I don't see why it would; the same basic requirements around CT apply regardless of certificate longevity. Any CA caught enabling this kind of MITM would be subject to expedient removal from browser root programs, but with the added benefit that their malfeasance would be self-healing over a much shorter period than was traditionally allowed.

fs111 2y ago

Load on the underlying infrastructure is a concern. The signing keys are all in HSMs and don't scale infinitely.

bob1029 2y ago
How does cycling out certificates more frequently reduce the load on HSMs?
- timmytokyo 2y ago
  It's all relative. A 47-day cycle increases the load, but a 48-hour cycle would increase it substantially more.
- woodruffw 2y ago
  Much of the HSM load within a CA is OCSP signing, not subscriber cert issuance.

timewizard 2y ago

If the service becomes unavailable for 48 straight hours then every certificate expires and nothing works. You probably want a little more room for catastrophic infrastructure problems.

notatoad 2y ago

>unless I've missed some monetary/power advantage the power dynamic here is that the CAs have a "too big to fail" inertia, where they can do bad things without consequence because revoking their trust causes too much inconvenience for too many people. shortening expiry timeframes to the point where all their certificates are always going to expire soon anyways reduces the harm that any one CA can do by offering bad certs. it might be inconvenient for you to switch your systems to accomodate shorter expiries, but it's better to confront that inconvenience up front than for it to be in response to a security incident.

mcpherrinm 2y ago

I'm on the team at Let's Encrypt that runs our CA, and would say I've spent a lot of time thinking about the tradeoffs here. Let's Encrypt has always self-imposed a 90 day limit, though of course with this ballot passing we will now have to reduce that under 47 days in the future. Shorter lifetimes have several advantages: 1. Reduced pressure on the revocation system. For example, if a domain changes hands, then any previous certificates spend less time in the revoked state. That makes CRLs smaller, a win for everyone involved. 2. Reduced risk for certificates which aren't revoked but should have been, perhaps because a domain holder didn't know that a previous holder of that domain had it, or an attack of any sort that led to a certificate being issued that wasn't desired. 3. For fully short-lived certs (under 7 days), many user-agents don't do revocation checks at all, because that's a similar timeline to our existing revocation technology taking effect. This is a performance win for websites/user-agents. While we advocate for full certificate automation, I recognize there are cases where that's not so easy, and doing a monthly renewal may be much more tractable. Going to shorter than a few days is a reliability and scale risk. One of the biggest issues with scale today is that Certificate Transparency logs, while providing great visibility into what certs exist (see points 1 and 2), will have to scale up significantly as lifetimes are cut. Why is this happening now, though? I can't speak for everyone, and this is only my own opinion on what I'm observing, but: One big industry problem that's been going on for the last year or two is that CAs have found themselves in situations where they need to revoke certificates because of issues with those certificates, but customers aren't able to respond on an appropriate timeline. So the big motivation for a lot of the parties here is to get these timelines down and really prove a push towards automation.

efortis 2y ago
4. Encrypted traffic hoarders would have to break more certs.
- throwaway2037 2y ago
  This one? https://en.wikipedia.org/wiki/Utah_Data_Center https://en.wikipedia.org/wiki/Utah_Data_Center
2y ago

michaelt 2y ago

> Once we cross the threshold of "I absolutely have to automate everything or it's not viable to use TLS anymore", why do we care about providing anything beyond ~48 hours? Well you see, they also want to be able to break your automation. For example, maybe your automation generates a 1024 bit RSA certificate, and they've decided that 2048 bit certificates are the new minimum. That means your automation stops working until you fix it. Doing this with 2-day expiry would be unpopular as the weekend is 2 days long and a lot of people in tech only work 5 days a week.

karlgkk 2y ago

> Why not make it 30 seconds? This is a ridiculous straw man. > 48 hours. I am willing to bet money this threshold will never be crossed. That's because it won't be crossed and nobody serious thinks it should. Short certs are better, but there are trade-offs. For example, if cert infra goes down over the weekend, it would really suck. TBH, from a security perspective, something in the range of a couple of minutes would be ideal, but that runs up against practical reasons - cert transparency logs and other logging would need to be substantially scaled up - for the sake of everyone on-call, you really don't want anything shorter than a reasonable amount of time for a human to respond - this would cause issues with some HTTP3 performance enhancing features - thousands of servers hitting a CA creates load that outweighs the benefit of ultra short certs (which have diminishing returns once you're under a few days, anyways) > This feels like much more of an ideological mission than a practical one There are numerous practical reasons, as mentioned here by many other people. Resisting this without good cause, like you have, is more ideological at this point.