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

> The objection that is most apropos is outlined again here,
> <https://infosec.exchange/@tqbf/109938525731567458>, that it is just
> another PKI and one where the CAs are the top-level-domain owners --
> governments. Thus, for example, if you have a domain in `.ly`, your CA
> is the government of Libya. For `.io`, it's whoever is in charge of
> that -- be it the British government, Mauritius, or private sector
> actors operating with the cooperation of one, the other, or both.

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.

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

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.

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:

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

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

 - "DNSSEC is Unnecessary"

   This argument is a pre-Let's Encrypt argument.  It now does not hold
   water.  Some here have already complained about LE in this thread.

 - "DNSSEC is a Government-Controlled PKI"

   Tackled above.

 - "DNSSEC is Cryptographically Weak"

   Also out of date.  Though one could instead mention the PQ issues I
   mentioned above.

 - "DNSSEC is Expensive To Adopt"

   This is mainly a matter of tooling and registry/registrar/zone
   support.

 - "DNSSEC is Expensive To Deploy"

   Ditto.

 - "DNSSEC is Incomplete"

   This is about _most_ clients leaving the SEC part of DNSSEC to
   someone else's recursive server.  But again, TFA is from 2015 and we
   now have Google and others operating their own DoH/DoT recursors for
   their browser's users rather than letting their users use the local
   ISP's/coffee shop's recursors.

   So a) anyone can run their own validating recursor in their laptops
   (smart phones and such is harder, since we have to depend on their
   walled garden vendors to give us the option), and b) any browser can
   use 1.1.1.1 or 8.8.8.8 etc.

   Also one can in principle use one's own validating recursor while
   routing queries through someone else's DoH/DoT servers so as to get a
   modicum of privacy (i.e., don't let the coffee shop / ISP see what
   sites you're calling).

   Of course, letting someone else's recursor do signature validation is
   a problem, but it's not _required_ by DNSSEC -- it's an option.
   Perhaps the option should never have been included, and perhaps it
   should be deprecated, but it's not fatal to DNSSEC.

 - "DNSSEC is Unsafe"

   This argument depends on "[b]ut DNSSEC is designed for offline
   signers; it doesn’t encrypt on the fly", where I think Thomas meant
   "sign" instead of "encrypt", and anyways that's not true: some CDNs
   sign RRSets on the fly specifically so that they can generate NSEC3
   non-existence proofs.  Basically this entire argument is obsolete,
   but then TFA is a decade old.

 - "DNSSEC is Architecturally Unsound"

   This argument is of the same sort that would lead one to think that
   securing BGP is silly.  For better or worse lots of things depend on
   the security of DNS, making BGP hijacking a serious problem, and so
   making the securing of both BGP _and_ DNS desirable.

 - "DNSSEC doesn’t have to happen. Don’t support it."

   If the other arguments against DNSSEC are not sound, then this
   exhortation isn't either.

Nico
--