Let's Encrypt is preparing for an emergency and that's good for TLS in general

February 10, 2021

Recently I read Let's Encrypt's Preparing to Issue 200 Million Certificates in 24 Hours (via), which is a high level view of exactly what the title says. Let's Encrypt isn't anywhere near that volume level in normal operation, but their reason to prepare for much, much more is a good one, so good that I'll just quote the start of their article:

On a normal day Let’s Encrypt issues nearly two million certificates. When we think about what essential infrastructure for the Internet needs to be prepared for though, we’re not thinking about normal days. We want to be prepared to respond as best we can to the most difficult situations that might arise. In some of the worst scenarios, we might want to re-issue all of our certificates in a 24 hour period in order to avoid widespread disruptions. [...]

This preparation is a good thing for at least three reasons. The first reason is that someday Let's Encrypt might actually have an emergency where the current rules for CAs would require them to revoke and thus reissure all of their certificates in a day (the rules are set through the CA/Browser Forum, although in practice set by browsers). Since Let's Encrypt certificates turn over rapidly, a core flaw in (say) parameters in the signed TLS certificates that they issue that wasn't detected for a few months could poison most or all of their current certificates, theoretically forcing mass revocations and reissuing according to the CA/B rules.

The second reason is that if Let's Encrypt (and the clients for it) are prepared for such a mass reissuing, it becomes much more likely that Let's Encrypt will actually do this and the browsers will require them to if such a problem was discovered. If Let's Encrypt could not handle a mass reissuing scenario, there would be at least a lot of practical pressure to not force them to revoke all of those certificates, and to bend the nominal CA/B rules in favor of practical security.

(If Let's Encrypt revoked a mass of certificates that they couldn't reissue on the spot, the two practical effects would be to demonstrate once again how little TLS certificate revocation actually does and to take a potentially significant number of HTTPS websites off the air. Since Firefox checks OCSP status and Chrome doesn't, this would probably also drive more people from Firefox to Chrome, which is not good for the web ecology.)

The third reason is that this puts pressure on all of the other TLS Certificate Authorities out there to also be prepared, and makes it more likely that the browser vendors will force other CAs to live up to the CA/B rules even if this would revoke a lot of current certificates. If Let's Encrypt is prepared, then everyone can point to Let's Encrypt and say 'you should have seen this coming and been ready, just like they were'. It also means that Let's Encrypt may be better placed to absorb a flood of new certificates if some other CA has to do a mass revocation and affected people turn to Let's Encrypt for even one-time TLS certificates to bridge them over.

(Not letting Certificate Authority mistakes and errors slide is good for the overall TLS ecosystem, especially since many CAs are in effect the weakest point in TLS security in practice. In the past this has happened for various reasons, although I think that the CA/B rules (and the browsers) were weaker then.)

PS: Given things like Heartbleed, flaws in Certificate Authority practices aren't the only thing that could trigger a need for a mass revocation and reissuance. Although another issue like Heartbleed should hopefully not have quite as large a blast radius as all of Let's Encrypt's certificates.

Written on 10 February 2021.
« The issue of IOPS versus latency on SSDs and NVMe drives
Getting high IOPS requires concurrency on modern SSDs and NVMe drives »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Feb 10 22:44:58 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.