Let's Encrypt DST Root CA X3 Expiration

[raf]

On Sat, Oct 02, 2021 at 08:56:18PM -0700, Michael <keybounce at gmail.com> wrote:

> ugh. Well, doing a search shows a LOT of articles about this very
> issue -- this was apparently a known "this is going to affect a lot of
> people" deal, and "just update your software, or ... sorry." was the
> only answer.
> 
> But, I at least did find out why certs expire. 
> Seriously though: A cert identifies a domain. If you sell/buy a
> domain, you want to be able to invalidate all existing certs for that
> domain.
> 
> And as I see that, I'm immediately struck by two things:
> 1. SSL, and a cert's job, is to validate the connection, not the
> person on the other end. It's to prevent MitM attacks. (Putting the
> domain name in -- when multiple names can go to the same server? Why?)

Warning: Not an expert!

I'm not sure I understand what you're asking here.
Certificates don't validate the connection.
They do validate the system on the other end.

Certificates prevent MITM attacks by validating the
server to the client (and sometimes by validating the
client to the server as well). It makes sense for the
domain to be in the certificate, because that's the
"identity" what the client thinks they are connect to.
If the domain wasn't there, what's being validated?
What would stop a MITM attack from replacing one
anonymous certificate with another anonymous
certificate? In some systems, it's possible to use
certificate or key fingerprints instead of domain names
to identify the party at the other end of a TLS
connection, but it's usually much less scalable than
using domain names.

> 2. The DNS is the obvious place to put "Here's our fingerprint" or
> something to validate a cert -- that would prevent old owner certs
> from working. (So why isn't this done?)

That can be done, and it is done on a tiny but ever
increasing scale. It's called DNS-based Authentication
of Named Entities (DANE). And it's great. You don't
need Certificate Authorities at all (if every TLS
client were DANE-aware, which they aren't). Every
domain owner can authenticate their own certificates.
The problem is that it relies on the security provided
by DNSSEC. Without DNSSEC, you just can't trust DNS.
With DNSSEC, you can trust DNS enough to authenticate
all sorts of things.

Luckily, DNSSEC has recently become incredibly easy to
implement. Google's DNS hosting service supports DNSSEC
with a checkbox. The recently released new debian
stable has a version of the Bind9 DNS server that is
recent enough that turning on DNSSEC can be done with a
single line of configuration (or a few) and a single
(or annual) manual interaction with your domain
registrar. It used to be much more complicated. And
that's the reason it isn't done. And the fact that
DNSSEC traffic is much larger than normal DNS traffic
(but well worth it, and it's less with modern keys than
it was when DNSSEC started).

But DNSSEC deployment is still a very small percentage
of all domains, and until it's much closer to 100%,
there's little chance that all web browsers will be
DANE-aware. There are attempts to include
DANE-awareness inside the TLS protocol itself as an
extension which would help. But it all seems a long way
off. It's currently mostly used for mail servers to
protect server-to-server traffic from MITM downgrade
attacks.

> And I cannot find any good reason for expiring root certs. They
> explicitly have much longer lifespans than anything else, and this
> isn't the first time that root certs have gone poof.

And it won't be the last. Hopefully, this episode will
teach creaters of IoT systems and operating systems
that no device should ever be designed to ever stop
keeping itself up-to-date (at least as far as root
certificates and TLS implementations are concerned). :-)

I think root certificates need to expire so as to
ensure that people take into account the fact that all
keys and certificates might need to be replaced one
day, and so provisions must be made to prepare for that
inevitability. If root certificates never expired,
people would almost certainly design systems with the
assumption that they would last forever. But they
won't. Nothing ever does. Death comes to us all. It's
dangerous to assume that no root certificate will ever
be compromised and will never have to be revoked. It's
better to assume that it will happen. So everyone has
to accept the fact that root certificates will need to
disappear at some point, for one reason or another, and
it's better to build that expectation into the system
as regular events, rather than only building it in as
catastrophic events. And there are other reasons why
root certificates will need to be replaced such as
better algorithms appearing, or quantum cryptanalysis
breaking all current public key cryptography, or just
the existing algorithms individually being broken.

The short answer is that the need for responsible
cryptographic key management applies at least as much
to root keys as it does to any other keys.

> Off the list topic now. Thanks for  your help.

cheers,
raf