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

[Jon Callas]

> On Apr 23, 2025, at 14:06, Nico Williams <nico at cryptonector.com> wrote:
> 
> On Wed, Apr 23, 2025 at 12:28:41PM -0700, Jon Callas wrote:
>>> What are the downsides to DNSSEC? Both honest and real, and imagined
>>> or excuses.
>> 
>> If you haven't read Tom Ptacek's "Against DNS"
>> <https://sockpuppet.org/blog/2015/01/15/against-dnssec/>, you should.
>> While not every one of his comments are things everyone agrees with,
>> the points are all well-argued.
> 
> 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.

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

> 
> Do the governments own and operate the registries and registrars?  Not
> anymore than they own and operate the WebPKI CAs, but in principle no
> registry, no registrar, and no CA can escape their clutches.  The only
> saving grace for WebPKI is that it has CT (certificate transparency),
> which can catch MITMing [after the fact], while DNSSEC doesn't have CT
> (but could; also see below).

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.

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

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.

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

However, imagine people with the imagination to create the likes of QUANTUM INSERT etc. and let them make a root domain server that gives different answers to different people. I think the job is actually easier. 

> 
>    - WebPKI has CT precisely to catch misbehaving CAs (which includes
>      nation states forcing them to MITM)
> 
> The key advantage that DNSSEC has is that the naming constraints.  The
> key advantage that WebPKI has is CT.
> 
> CT is one of only two reasons (IMO) to think WebPKI superior to DNSSEC.
> The other is PQ: DNSSEC is more constrained as to PQ PK scheme choices
> than WebPKI because larger keys and signatures will not be practical in
> DNS.
> 
> By the way, some day we can expect non-public court rulings here and
> there to force CAs to MITM CT-be-damned.  The CA/Browser forum might not
> look kindly on those CAs that give in at first, but when enough of them
> are under the gun...
> 
> Another objection one might have is that one has to use QName
> minimization in order to disincentivize real-time MITMing by the root
> servers, though not by TLD/ccTLD registries, and QName minimization can
> add one more round trip in some cases (oh noes!).  QName minimization is
> a partial mitigation for DNSSEC not having CT [yet].  But I don't think
> that would be a big objection.
> 
> 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. 

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).

> 
>> It's thus completely possible for that owning government to have an
>> alternate DNSSEC and flip between them at will. John Gilmore reminded
>> us of the QUANTUM <thing> projects done in the past, and DNSSEC makes
>> the concept possible with a new implementation.
> 
> What they would have is a device that has root keys (or more likely: can
> call on a remote device that does) that they can deploy at will (where
> they can) to act as an on-the-wire MITM.  However, having the keys for
> all TLDs and ccTLDs can be difficult, so QName minimization + wisely
> picking TLDs for your sites is a very decent mitigation until DNSSEC CT
> materializes and even after (since you don't want to have to catch the
> MITM that gets you the rubber hose cryptanalysis ex post -- you want to
> dissuade them even before then).
> 
>> Other criticisms of DNSSEC are not directly relevant, but are more
>> than obliquely relevant. For example, there are reliability criticisms
>> that could be fixed, but it's not clear that the fixes to network
>> infrastructure would improve the trust system.
> 
> 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.

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

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.

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.

	Jon