[Cryptography] Against against DNS (Re: New SSL/TLS certs to each live no longer than 47) days by 2029

[Nico Williams]

On Wed, Apr 23, 2025 at 03:43:01PM -0700, Jon Callas wrote:
> > That's a decade old and out of date.  I've had this argument with Thomas
> > on HN several times.  Is there a more up to date version of this?
> > Anyways, my take is below.  The new subject is the "TL;DR".
> 
> Is it out of date?
> 
> The Geoff Huston essay that Michael Kjörling posted,
> <https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/>, is from
> May 2024 and jibes with it pretty much. Nine years pass, and while
> some of the lyrics might have changed, the song is still the same.

That addresses just the cost of deployment.  I would not say that one is
out of date, but it doesn't echo any but the deployment costs issues
from Thomas' decade-old blog.  I.e., in many ways either things have
improved or Thomas' negative take not supported.

> > Let's start with that objection that it's a government-controlled PKI.
> > Is the WebPKI not that too?  At the limit we all know that it is.
> 
> I think that relevant to us, that's the primary argument. I summarize
> it as moving from WebPKI to DANE etc. is just swapping a flawed trust
> system for another flawed trust system. The flaws are not the same,
> and yet there are analogues between them. 

Please do not lose sight of the fact that we could insist on both, DANE
_and_ WebPKI.  What does that get us?  Mainly a) a mitigation for
DNSSEC's lack of CT, b) nonexistence proofs, c) a path away from WebPKI
should we end up needing it, d) name constraints.  (d) is not merely
academic.  The whole problem with WebPKI is that there are so many
roots, and that made CT much more urgent for WebPKI than for DNSSEC
because it's the only mitigation available for the lack of name
constraints (pinning approaches are another mitigation, and pinning was
tried but failed).

> > Do the governments own and operate the registries and registrars?
> > ...
> 
> I think it depends. I think one can make the argument that bringing up
> the `.io` TLD was controlled by the British government has a lot of
> handwaving and vague threats that put their toes up to the line of
> conspiracy theory. But now, it's being handed over to Mauritius. Are
> they any better? Look at the trendy CCTLDs that people have used over
> the years and there's little reason to think they were compromised,
> and at the same time little reason to think they're secure. I'm not
> giving up my vanity domains, and don't think there's a threat from
> them. At the same time, if I get mad at a CA I can switch to another
> one, but if I have a domain protected only by DNSSEC the remedy for "I
> just don't trust them" is to move to another TLD.

Remember the DANE TLSA RR PKIX-TA certificate usage.

> > A better objection would be that there is only one root CA in DNSSEC,
> > except that such an objection is wrong: we can all run our own roots
> > refreshed nightly / weekly, and our own recursors.  It's true that it's
> > much harder to run one's own private servers for TLDs and ccTLDs though.
> 
> I have a raised eyebrow. "We" in the sense of people on this list
> likely can. It doesn't scale as far as our reasonably close yet
> extended families. 

Certainly Apple and Google could choose to make that easy.  Perhaps
third party apps could make it easy.

> Strictly speaking, I do not believe that I could run my own DNS as
> well as any of the major people (1.1.1.1, 8.8.8.8, and so on) do now.

For just the root?  It's a nightly cron job to transfer the latest.

> > Fundamentally what this breaks down into is this:
> > 
> > - DNSSEC is a PKI with naming constraints from the get-go, and that
> >   forces a proper hierarchy, which seems easier for nation states to
> >   target, while
> > 
> > - WebPKI is a PKI w/o naming constraints and which now can't have
> >   naming constraints added, which... makes it even easier for nation
> >   states to target, except for:
> 
> Ummm, it has naming constraints. Are they perfectly adequate for
> what's needed? No. They do exist, though, and perhaps ironically
> government intrusion in this space (yup, I'm looking at you, QWACs) is
> forcing better constraints by intruding into that space.

Do any WebPKI CAs use name constraints?  Are they marked critical?  Do
the relying parties check them?

> > Another objection might be the lack of encryption of DNS queries (paging
> > DJB!), but DoT and DoH nowadays solves that [at the low low price of
> > letting a recursor operator see your queries instead of your ISP or
> > coffee shop, which all things considered is a reasonable price, though
> > not great].  But WebPKI doesn't cure this, so this would not be a valid
> > objection to DNSSEC as opposed to WebPKI, but it is indeed a valid
> > complaint about DNSSEC.
> 
> Right. Do[HT] fixes a different problem.
> 
> There are a number of issues that get conflated together, for example,
> an MITM and passive snooping. They're not the same. They're different
> problems with different solutions. 

For sure.  (I did not conflate them.)

> Do[HT] does not fix the problem of an evil root resolver. It might
> make the problem worse, but those issues could be fixed (like with an
> analogue of CT for it).

Yes.  QName minimization does help mitigate against evil roots by
denying them context and forcing them to commit to MITMing too early, as
well as forcing them to MITM TLDs.

> > Looking at Thomas' arguments:
> 
> As you noted, the essay's a decade old. I didn't bring those up
> because we're primarily talking about the cryptographic aspect, rather
> than the networking ones. Also, even at the time, I didn't agree 100%
> with the totality of it despite thinking that they're good points.

That's fair.  I took your linking it as an opportunity to address its
points to a relevant audience.

> Networking matters, not the least because there are literally
> trillions of DNS requests per day, and performance, reliability, and
> other *networking* matters matter here. The Geoff Huston article has
> updated discussions of those, and they seem to me to be insightful,
> even if I don't agree with them.

I still have to read his blog post carefully.  I am sure he would get
these things right though, so I presume he's right.

> I think that the most germane comment Huston made was that if DNSSEC
> had been built from the ground up to offer a trust system to TLS,
> maybe it could have. I am skeptical because I remember DNSSEC
> development and what a long, arduous slog it was. Nonetheless, I can
> imagine an alternate universe in which we had a viable DNSSEC
> alternative. We just don't. That's not the way the cards fell.

Yes, this is quite true, but it doesn't preclude DANE forever, only
_now_.  Not unlike how IPv6 development and deployment has gone.

> Despite this, WebPKI has a feature that is relevant -- it separates
> the *application* path from the *address* path. Huston at least talks
> around this when he talks about the way that TLS and DNSSEC are
> solving different problems. WebPKI has the advantage that there are
> separate paths for trust evaluation and address evaluation. Moreover,
> if we strengthen address evaluation with bog-standard DNSSEC --
> suppose a successful campaign to get everyone to use it, for example
> -- then that strengthens WebPKI, too, and makes the rationale to make
> a technical change even harder.

WebPKI w/o CT doesn't really have a trustworthy path for "trust
evaluation" because of the lack of meaningful name constraints, which is
to say because of the multiplicity of roots.  CT helps, but requires
monitoring and alerts to illicit certificate issuance after the fact.

> I think that WebPKI is at best a thrown-together kluge tower. And yet
> it's a kluge tower that works good enough. In that alternate world of
> WebDNSSEC, it's also a kluge tower, and I am certain that it could be
> made as good as WebPKI, with enough work in it. I am not sure that
> it's better, just differently, perhaps slightly less klugy. The
> existing WebPKI (and let us not forget the impact of LetsEncrypt)
> along with actually deployed DNSSEC would be better than either one of
> those alone.

It was the only kludge we had in the mid-90s, and DANE was not
available.  It's no surprise that WebPKI has dominated since then: it
was the only game in town for long enough to develop mitigations for its
flaws.

Nico
--