[Cryptography] New SSL/TLS certs to each live no longer than 47 days by 2029

[Michael Kjörling]

On 23 Apr 2025 13:12 -0700, from ron at flownet.com (Ron Garret):
> *That* is what certificates protect against. DNSSEC will not help
> you at all because as long as you are connected to my hot spot, I
> control the entire Internet from your point of view, not just DNS.

Yes.

That's essentially the key security-related takeaway from Geoff
Huston's text, as I read it. There are other points as well, and for
anyone who hasn't, I strongly encourage reading it.

In an ideal world where everything works exactly as intended, having
DNSSEC (and only DNSSEC) secures the mapping between the host name and
the ultimate IP address returned by the name service, but does not
authenticate or secure the established communications channel. Anyone
with access to the network path between my system and the network
location of the host I connect to can store, inspect and modify the
traffic while in transit, even if we also postulate secure routing
(such that if I connect to 192.0.2.1 the network guarantees that
wherever I end up is at a legitimate holder of 192.0.2.1 and not
anything else). In the presence of a passive eavesdropper or an active
attacker willing to manipulate traffic, holistically speaking, the
system fails open. The active attacker can also, at will, cause name
resolution to fail, causing the system to fail closed.

In the same world, having TLS PKI (and only TLS PKI) means I might be
communicating with a host at some IP address unrelated to the actual
IP address of the host I intended to communicate with (as defined by
the intentions of whoever legitimately controls the host name in
question in DNS), but this will become obvious quickly because the
software on _my_ system has no reason to trust that the rogue host I
ended up connecting to is authorized to provide service at the host
name I intended to connect to, because the rogue host cannot
demonstrate this authorization to a third party such as a widely
trusted CA. (The presence of CAA RRs in DNS can further narrow down
the set of CAs. For example, if someone were to try to get a rogue
certificate issued for my web site's host name, they would need to not
just fool one particular CA but _also_ fool that particular CA into
believing that the attacker controls one specific account with them,
or alternatively fool a CA which is still widely trusted but has an
issuance path which ignores CAA RRs.) A passive eavesdropper cannot
read or modify the encrypted traffic; an active attacker can prevent
communications. The system fails closed.

If we postulate a world in which DNSSEC works as it is designed and
intended to be used, then it seems reasonable to correspondingly
postulate a world in which TLS PKI works as it is designed and
intended to be used.

If we postulate a government threat actor willing to take the risk of
discovery by both actively manipulating the communications and either
itself or via some widely trusted CA it can exert control over issue
certificates even at the risk of this being discovered, a lot of
security guarantees of _both_ DNSSEC _and_ TLS PKI go out the window.
Which is what CT is for; it doesn't _prevent_ that, but it offers a
way to after the fact show that it _was_ done.

Perfect is nice. But if we always held out for perfection, we
certainly wouldn't be having this discussion because there would exist
no such thing as the Internet, or e-mail.

-- 
Michael Kjörling
🔗 https://michael.kjorling.se