[Ach] DNSSEC [was: Re: filippo on SSL SMTP encryption]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue Mar 31 21:17:56 CEST 2015


While i share some of Aaron's skepticism about DNSSEC's technical
prospects, and quite a lot of his skepticism about putting all our eggs
in the hierarchical structure of the DNS, i actually am less pessimistic
overall about DNSSEC in general.

We need *more* functional authentication systems, and we need to be able
to use them in corroborative ways.  DNSSEC strikes me as a mechanism
that can be used alongside CAs or WoT or TOFU as an additional verifier.

On Tue 2015-03-31 14:35:13 -0400, Aaron Zauner wrote:
> This protocol has such a bright future that in 15 years since the first
> talk about standardization it has been under constant change, is still
> changing (people are talking about NSEC5 right now) and it still does
> not _fucking_ work.

NSEC5 is a proposal to provide both non-enumerable zones and
authenticated denial of existence (NXDOMAIN) responses while retaining
offline keys for the positive assertions.

If you're willing to place your zone-signing keys online, you can
already get non-enumerable zones with authenticated denial of existence.
And if you're willing to have your zone be enumerable, you can already
get offline keys with authenticated denial of existence.  so NSEC5 is
really tuning one little corner use case that is otherwise unhandled.

I don't think it's worthwhile to critique the protocol as a whole for
the fact that people are trying to address corner use cases like this (i
do know some people who want both offline zone-signing keys and
non-enumerable zones; those people are rare, but as more information
gets placed into the DNS, non-enumerability and offline ZSKs may become
more desirable).

As for moving the verification to the resolver, that's obviously a
losing prospect, since it just puts your trust in an unreliable remote
host (and over insecure transport, even, in the common DNS use case!).
What we need is for resolvers to transfer the entire signing chain to
the stub so that verification can take place on the local client.

     --dkg



More information about the Ach mailing list