[Ach] DNSSEC [was: Re: filippo on SSL SMTP encryption]
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Mar 31 22:14:49 CEST 2015
On Tue 2015-03-31 15:41:22 -0400, Aaron Zauner wrote:
> Daniel Kahn Gillmor wrote:
>> 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.
> That would make sense, but I don't know of any implementation or any
> effort towards this. Do you have more information on that? That would at
> least solve the client-side issues. Issues with the trust chain are
> still unchanged by that. I've seen a proposal for certificate
> transparency with DNSSEC
> (https://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00) hasn't got
> toom uch attention tough.
We talked about that draft in the trans working group meeting at
IETF-91. It got a lot of pushback because it was (i think) overly
ambitious and people were freaking out about how much data it would be
I think the safer way to move forward with dnssec transparency is to
just log the root zone, to demonstrate feasibility at one layer.
I actually don't think that dnssec-trans makes sense all the way down to
the leaves of the DNS tree, because of the zone enumerability issue: if
i'm using OPENPGPKEY records in my zone, i don't want you to be able to
see every user that i have just by reading the logs.
So demonstrating that it works to detect misissuance from a high-value,
heavily-centralized node is what we really want, and i don't know of
anyone who would claim that the root zone isn't worth monitoring for
If anyone on this list is interested in pushing this forward, i'd be
happy to talk to them about it, i just don't have a lot of time to push
it forward myself.
More information about the Ach