16 ms·

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-impo

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
delfinom 2y ago
Realistically, how often are domains traded and suddenly put in legitimate use (that isn't some domain parking scam) that (1) and (2) are actual arguments? Lol
- zamadatix 2y ago
  Domain trading (regardless if the previous use was legitimate or not) is only one example, not the sole driving argument for why the revocation system is in place or isn't perfectly handled.
0xbadcafebee 2y ago
So it's being pushed because it'll be easier for a few big players in industry. Everybody else suffers.
- ignoramous 2y ago
  Unless I misunderstood, GP mentions that the problem stems from WebPKI's central role in server identity management. Think of these cert lifetimes as forcefully being signed out after 47 days of being signed in. > easier for a few big players in industry Not necessarily. OP mentions, more certs would mean bigger CT logs. More frequent renewals mean more load. Like with everything else, this seems like a trade-off. Unfortunately, for you & I, as customers of cert authorities, 47 days is where the now the agreed cut-off is (not 42).
- tptacek 2y ago
  Or, equivalently, it's being pushed because customers of "big players", of which there are a great many, are exposed to security risk by the status quo that the change mitigates.
- mcpherrinm 2y ago
  It makes the system more reliable and more secure for everyone. I think that's a big win. The root reason is that revocation is broken, and we need to do better to get the security properties we demand of the Web PKI.
  - fiddlerwoaroof 2y ago
    It makes systems more reliable and secure for system runners that can leverage automation for whatever reason. For the same reason, it adds a lot of barriers to things like embedded devices, learners, etc. who might not be able to automate TLS checks.
    - thayne 2y ago
      Putting a manually generated cert on an embedded device is inherently insecure, unless you have complete physical control over the device. And as mentioned in other comments, the revocation system doesn't really work, and reducing the validity time of certs reduces the risks there. Unfortunately, there isn't really a good solution for many embedded and local network cases. I think ideally there would be an easy way to add a CA that is trusted for a specific domain, or local ip address, then the device can generate its own certs from a local ca. And/or add trust for a self-signed cert with a longer lifetime.
Lammy 2y ago
> but customers aren't able to respond on an appropriate timeline Sounds like your concept of the customer/provider relationship is inverted here.
- crote 2y ago
  No. The customer is violating their contract. The whole "customer is king" doesn't apply to something as critical as PKI infrastructure, because it would compromise the safety of the entire internet. Any CA not properly applying the rules will be removed from the trust stores, so there can be no exceptions for companies who believe they are too important to adhere to the contract they signed.
  - luckylion 2y ago
    How would a CA not being able to contact some tiny customer (surely the big ones all can and do respond in less than 90 days?) compromise the safety of the entire internet? And if the safety of the entire internet is at risk, why is 47 days days an acceptable duration for this extreme risk, but 90 days is not?
    - detaro 2y ago
      > surely the big ones all can and do respond in less than 90 days? LOL. old-fashioned enterprises are the worst at "oh, no, can't do that, need months of warning to change something!", while also handling critical data. A major event in the CA space last year was a health-care company getting a court order against a CA to not revoke a cert that according to the rules for CAs the CA had to revoke (in the end they got a few days extension, everyone grumbled and the CA got told to please write their customer contracts more clearly, but the idea is out there and nobody likes CAs doing things they are not supposed to, even if through external force). One way to nip that in the bud is making sure even you get your court order preventing the CA from doing the right thing, your certificate will expire soon anyways, so "we are too important to have working IT processes" doesn't work anymore.
      - 2y ago
grey-area 2y ago
Since you’ve thought about it a lot, in an ideal world, should CAs exist at all?
- Stefan-H 2y ago
  What alternatives come to mind when asking that question? Not being in the PKI world directly, web of trust is what comes to mind, but I'm curious what your question hints at.
  - grey-area 2y ago
    I honestly don’t know enough about it to have an opinion, have vague thoughts that dns is the weak point anyway for identity so can’t certs just live there instead but I’m sure there are reasons (historical and practical).
- Ajedi32 2y ago
  In an ideal world where we rebuilt the whole stack from scratch, the DNS system would securely distribute key material alongside IP addresses and CAs wouldn't be needed. Most modern DNS alternatives (Handshake, Namecoin, etc) do exactly this, but it's very unlikely any of them will be usurping DNS anytime soon, and DNS's attempts to implement similar features have been thus far unsuccessful.
  - tptacek 2y ago
    People who idealize this kind of solution should remember that by overloading core Internet infrastructure (which is what name resolution is) with a PKI, they're dooming any realistic mechanism that could revoke trust in the infrastructure operators. You can't "distrust" .com. But the browsers could distrust Verisign, because Verisign had competitors, and customers could switch transparently. Browser root programs also used this leverage to establish transparency logs (though: some hypothetical blockchain name thingy could give you that automatically, I guess; forget about it with the real DNS though).
    - 2y ago
hsbauauvhabzb 2y ago
How viable are tls attacks, assuming a signed private cert is compromised, you need network position or other things to trigger routing, no? So for a bank, a private cert compromise is bad, for a regular low traffic website, probably not so much?
noveltyaccount 2y ago
When I first set up Let's Encrypt I thought I'd manually update the cert one per year. The 90 day limit was a surprise. This blog post helped me understand (it repeats many of your points) https://letsencrypt.org/2015/11/09/why-90-days/ https://letsencrypt.org/2015/11/09/why-90-days/
ocdtrekkie 2y ago
Are you aware of a single real world not theoretical security breach caused by an unrevoked certificate that lived too long?
- woodruffw 2y ago
  A real-world example of this would be Heartbleed, where users rotated without revoking their previously compromised certificates[1]. [1]: https://en.wikipedia.org/wiki/Heartbleed#Certificate_renewal_and_revocation https://en.wikipedia.org/wiki/Heartbleed#Certificate_renewal...
  - ocdtrekkie 2y ago
    Was a single certificate actually compromised and/or used maliciously? I am looking for an actual breach, not a theoretical scenario.
    - ferngodfather 1y ago
      Based on that Wikipedia article, no. This is just more of the same friendless PKI geeks making the world unnecessarily more complicated. The only other people that benefit are the certificate management companies that sell more software to manage these insane changes.
      - woodruffw 1y ago
        Did you read it? There are multiple examples of claimed exploitation right below the section I linked.
        ferngodfather 1y ago
        Which bit says about stealing a certificate/keys and MITMing traffic with the stolen keys - with real world ramifications?
    - woodruffw 1y ago
klaas- 2y ago
I think a very short lived cert (like 7 days) could be a problem on renewal errors/failures that don't self correct but need manual intervention. What will let's encrypt be like with 7day certs? Will it renew them every day(6 day reaction time), or every 3 days (4 days reaction time). Not every org is suited with 24/7 staffing, some people go on holidays, some public holidays extend to long weekends etc :). I would argue that it would be a good idea to give people a full week to react to renewal problems. That seems impossible for short lived certs.
- iqandjoke 2y ago
  Like Apple case. Apple already ask their developer to re-sign the app every 7 days. It should not be the problem.
  - kassner 2y ago
    That’s only a thing if you are not publishing on Apple Store, no?
    - dcow 2y ago
      Correct. Or if you’re not using an enterprise distribution cert.
ryao 2y ago
Could you explain why Let's Encrypt is dropping OCSP stabling support, instead of dropping it for must-staple only certificates and letting those of us who want must-staple to deal with the headaches? I believe that resolving the privacy concerns involving OCSP raised did not require eliminating must-staple.
- mcpherrinm 1y ago
  Must-staple has almost zero adoption. The engineering cost of supporting it for a feature that is nearly unused just isn’t there. We did consider it. As CAs prepare for post-quantum in the next few years, it will become even less practical as there is going to be pressure to cut down the number of signatures in a handshake.
  - ryao 1y ago
    > Must-staple has almost zero adoption. The engineering cost of supporting it for a feature that is nearly unused just isn’t there. > We did consider it. That is unfortunate. I just deployed a web server the other day and was thrilled to deploy must-staple from Let's Encrypt, only to read that it was going away. > As CAs prepare for post-quantum in the next few years, it will become even less practical as there is going to be pressure to cut down the number of signatures in a handshake. Please delay the adoption of PQAs for certificate signatures at Let's Encrypt as long as possible. I understand the concern that a hypothetical quantum machine with tens of millions of qubits capable of running Shor's algorithm to break RSA and ECC keys might be constructed. However, "post-quantum" algorithms are inferior to classical cryptographic algorithms in just about every metric as long as such machines do not exist. That is why they were not even considered when the existing RSA and ECDSA algorithms were selected before Shor's algorithm was a concern. There is also a real risk that they contain undiscovered catastrophic flaws that will be found only after adoption, since we do not understand their hardness assumptions as well as we understand integer factorization and the discrete logarithm problem. This has already happened with SIKE and it is possible that similarly catastrophic flaws will eventually be found in others. Perfect forward secrecy and short certificate expiry allow CAs to delay the adoption of PQAs for key signing until the creation of a quantum computer capable of running Shor’s algorithm on ECC/RSA key sizes is much closer. As long as certificates expire before such a machine exists, PFS ensures no risk to users, assuming key agreement algorithms are secured. Hybrid schemes are already being adopted to do that. There is no quantum moore's law that makes it a forgone conclusion that a quantum machine that can use Shor's algorithm to break modern ECC and RSA will be created. If such a machine is never made (due to sheer difficulty of constructing one), early adoption in key signature algorithms would make everyone suffer from the use of objectively inferior algorithms for no actual benefit. If the size of key signatures with post quantum key signing had been a motivation for the decision to drop support for OCSP must-staple and my suggestion that adoption of post quantum key signing be delayed as long as possible is in any way persuasive, perhaps that could be revisited? Finally, thank you for everything you guys do at Let's Encrypt. It is much appreciated.
cm2187 2y ago
All of that in case the previous owner of the domain would attempt a mitm attack against a client of the new owner, which is such a remote scenario. In fact has it happened even once?
anakaine 2y ago
I love the push that LE puts on industry to get better. I work in a very large organisation and I just dont see them being able to go to automated TLS certificates for their self managed subdomains, inspection certificates, or anything else for that matter. It will be interesting to see how the short lived certs are adopted into the future.

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

delfinom 2y ago

Realistically, how often are domains traded and suddenly put in legitimate use (that isn't some domain parking scam) that (1) and (2) are actual arguments? Lol

zamadatix 2y ago
Domain trading (regardless if the previous use was legitimate or not) is only one example, not the sole driving argument for why the revocation system is in place or isn't perfectly handled.

0xbadcafebee 2y ago

So it's being pushed because it'll be easier for a few big players in industry. Everybody else suffers.

ignoramous 2y ago
Unless I misunderstood, GP mentions that the problem stems from WebPKI's central role in server identity management. Think of these cert lifetimes as forcefully being signed out after 47 days of being signed in. > easier for a few big players in industry Not necessarily. OP mentions, more certs would mean bigger CT logs. More frequent renewals mean more load. Like with everything else, this seems like a trade-off. Unfortunately, for you & I, as customers of cert authorities, 47 days is where the now the agreed cut-off is (not 42).
tptacek 2y ago
Or, equivalently, it's being pushed because customers of "big players", of which there are a great many, are exposed to security risk by the status quo that the change mitigates.
mcpherrinm 2y ago
It makes the system more reliable and more secure for everyone. I think that's a big win. The root reason is that revocation is broken, and we need to do better to get the security properties we demand of the Web PKI.
- fiddlerwoaroof 2y ago
  It makes systems more reliable and secure for system runners that can leverage automation for whatever reason. For the same reason, it adds a lot of barriers to things like embedded devices, learners, etc. who might not be able to automate TLS checks.
  - thayne 2y ago
    Putting a manually generated cert on an embedded device is inherently insecure, unless you have complete physical control over the device. And as mentioned in other comments, the revocation system doesn't really work, and reducing the validity time of certs reduces the risks there. Unfortunately, there isn't really a good solution for many embedded and local network cases. I think ideally there would be an easy way to add a CA that is trusted for a specific domain, or local ip address, then the device can generate its own certs from a local ca. And/or add trust for a self-signed cert with a longer lifetime.

Lammy 2y ago

> but customers aren't able to respond on an appropriate timeline Sounds like your concept of the customer/provider relationship is inverted here.

crote 2y ago
No. The customer is violating their contract. The whole "customer is king" doesn't apply to something as critical as PKI infrastructure, because it would compromise the safety of the entire internet. Any CA not properly applying the rules will be removed from the trust stores, so there can be no exceptions for companies who believe they are too important to adhere to the contract they signed.
- luckylion 2y ago
  How would a CA not being able to contact some tiny customer (surely the big ones all can and do respond in less than 90 days?) compromise the safety of the entire internet? And if the safety of the entire internet is at risk, why is 47 days days an acceptable duration for this extreme risk, but 90 days is not?
  - detaro 2y ago
    > surely the big ones all can and do respond in less than 90 days? LOL. old-fashioned enterprises are the worst at "oh, no, can't do that, need months of warning to change something!", while also handling critical data. A major event in the CA space last year was a health-care company getting a court order against a CA to not revoke a cert that according to the rules for CAs the CA had to revoke (in the end they got a few days extension, everyone grumbled and the CA got told to please write their customer contracts more clearly, but the idea is out there and nobody likes CAs doing things they are not supposed to, even if through external force). One way to nip that in the bud is making sure even you get your court order preventing the CA from doing the right thing, your certificate will expire soon anyways, so "we are too important to have working IT processes" doesn't work anymore.
    - 2y ago

grey-area 2y ago

Since you’ve thought about it a lot, in an ideal world, should CAs exist at all?

Stefan-H 2y ago
What alternatives come to mind when asking that question? Not being in the PKI world directly, web of trust is what comes to mind, but I'm curious what your question hints at.
- grey-area 2y ago
  I honestly don’t know enough about it to have an opinion, have vague thoughts that dns is the weak point anyway for identity so can’t certs just live there instead but I’m sure there are reasons (historical and practical).
Ajedi32 2y ago
In an ideal world where we rebuilt the whole stack from scratch, the DNS system would securely distribute key material alongside IP addresses and CAs wouldn't be needed. Most modern DNS alternatives (Handshake, Namecoin, etc) do exactly this, but it's very unlikely any of them will be usurping DNS anytime soon, and DNS's attempts to implement similar features have been thus far unsuccessful.
- tptacek 2y ago
  People who idealize this kind of solution should remember that by overloading core Internet infrastructure (which is what name resolution is) with a PKI, they're dooming any realistic mechanism that could revoke trust in the infrastructure operators. You can't "distrust" .com. But the browsers could distrust Verisign, because Verisign had competitors, and customers could switch transparently. Browser root programs also used this leverage to establish transparency logs (though: some hypothetical blockchain name thingy could give you that automatically, I guess; forget about it with the real DNS though).
  - 2y ago

hsbauauvhabzb 2y ago

How viable are tls attacks, assuming a signed private cert is compromised, you need network position or other things to trigger routing, no? So for a bank, a private cert compromise is bad, for a regular low traffic website, probably not so much?

noveltyaccount 2y ago

When I first set up Let's Encrypt I thought I'd manually update the cert one per year. The 90 day limit was a surprise. This blog post helped me understand (it repeats many of your points) https://letsencrypt.org/2015/11/09/why-90-days/ https://letsencrypt.org/2015/11/09/why-90-days/

ocdtrekkie 2y ago

Are you aware of a single real world not theoretical security breach caused by an unrevoked certificate that lived too long?

woodruffw 2y ago
A real-world example of this would be Heartbleed, where users rotated without revoking their previously compromised certificates[1]. [1]: https://en.wikipedia.org/wiki/Heartbleed#Certificate_renewal_and_revocation https://en.wikipedia.org/wiki/Heartbleed#Certificate_renewal...
- ocdtrekkie 2y ago
  Was a single certificate actually compromised and/or used maliciously? I am looking for an actual breach, not a theoretical scenario.
  - ferngodfather 1y ago
    Based on that Wikipedia article, no. This is just more of the same friendless PKI geeks making the world unnecessarily more complicated. The only other people that benefit are the certificate management companies that sell more software to manage these insane changes.
    - woodruffw 1y ago
      Did you read it? There are multiple examples of claimed exploitation right below the section I linked.
      - ferngodfather 1y ago
        Which bit says about stealing a certificate/keys and MITMing traffic with the stolen keys - with real world ramifications?
  - woodruffw 1y ago

klaas- 2y ago

I think a very short lived cert (like 7 days) could be a problem on renewal errors/failures that don't self correct but need manual intervention. What will let's encrypt be like with 7day certs? Will it renew them every day(6 day reaction time), or every 3 days (4 days reaction time). Not every org is suited with 24/7 staffing, some people go on holidays, some public holidays extend to long weekends etc :). I would argue that it would be a good idea to give people a full week to react to renewal problems. That seems impossible for short lived certs.

iqandjoke 2y ago
Like Apple case. Apple already ask their developer to re-sign the app every 7 days. It should not be the problem.
- kassner 2y ago
  That’s only a thing if you are not publishing on Apple Store, no?
  - dcow 2y ago
    Correct. Or if you’re not using an enterprise distribution cert.

ryao 2y ago

Could you explain why Let's Encrypt is dropping OCSP stabling support, instead of dropping it for must-staple only certificates and letting those of us who want must-staple to deal with the headaches? I believe that resolving the privacy concerns involving OCSP raised did not require eliminating must-staple.

mcpherrinm 1y ago
Must-staple has almost zero adoption. The engineering cost of supporting it for a feature that is nearly unused just isn’t there. We did consider it. As CAs prepare for post-quantum in the next few years, it will become even less practical as there is going to be pressure to cut down the number of signatures in a handshake.
- ryao 1y ago
  > Must-staple has almost zero adoption. The engineering cost of supporting it for a feature that is nearly unused just isn’t there. > We did consider it. That is unfortunate. I just deployed a web server the other day and was thrilled to deploy must-staple from Let's Encrypt, only to read that it was going away. > As CAs prepare for post-quantum in the next few years, it will become even less practical as there is going to be pressure to cut down the number of signatures in a handshake. Please delay the adoption of PQAs for certificate signatures at Let's Encrypt as long as possible. I understand the concern that a hypothetical quantum machine with tens of millions of qubits capable of running Shor's algorithm to break RSA and ECC keys might be constructed. However, "post-quantum" algorithms are inferior to classical cryptographic algorithms in just about every metric as long as such machines do not exist. That is why they were not even considered when the existing RSA and ECDSA algorithms were selected before Shor's algorithm was a concern. There is also a real risk that they contain undiscovered catastrophic flaws that will be found only after adoption, since we do not understand their hardness assumptions as well as we understand integer factorization and the discrete logarithm problem. This has already happened with SIKE and it is possible that similarly catastrophic flaws will eventually be found in others. Perfect forward secrecy and short certificate expiry allow CAs to delay the adoption of PQAs for key signing until the creation of a quantum computer capable of running Shor’s algorithm on ECC/RSA key sizes is much closer. As long as certificates expire before such a machine exists, PFS ensures no risk to users, assuming key agreement algorithms are secured. Hybrid schemes are already being adopted to do that. There is no quantum moore's law that makes it a forgone conclusion that a quantum machine that can use Shor's algorithm to break modern ECC and RSA will be created. If such a machine is never made (due to sheer difficulty of constructing one), early adoption in key signature algorithms would make everyone suffer from the use of objectively inferior algorithms for no actual benefit. If the size of key signatures with post quantum key signing had been a motivation for the decision to drop support for OCSP must-staple and my suggestion that adoption of post quantum key signing be delayed as long as possible is in any way persuasive, perhaps that could be revisited? Finally, thank you for everything you guys do at Let's Encrypt. It is much appreciated.

cm2187 2y ago

All of that in case the previous owner of the domain would attempt a mitm attack against a client of the new owner, which is such a remote scenario. In fact has it happened even once?

anakaine 2y ago

I love the push that LE puts on industry to get better. I work in a very large organisation and I just dont see them being able to go to automated TLS certificates for their self managed subdomains, inspection certificates, or anything else for that matter. It will be interesting to see how the short lived certs are adopted into the future.