[dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Paul Wouters <[e-mail]>]

On Wed, 3 Jun 2020, Peter van Dijk wrote:

>
> We have definitely thought about that! The way this signaling protocol is structured means that we cannot see DNSKEY flags until we have established some encrypted connection (in our case, DoT). So flags are out. I think it would be simplest to allocate one 'algorithm' number per protocol. This would also allow protocols other than DoT to perhaps use the various DNSKEY/DS fields for different semantics.

I had a discussion with Viktor Dukhovni about the concepts of the draft.

We kind of came to the following conclusion:

If you need EPP and/or Registry and Registrar support for new things,
this is not really going to get deployed at scale. (and we need scale
to hide)

Syncing between domain owner and nameserver operator for public keys is
basically impossible. While it might work manually for one domain,
imagine GoDaddy or Cloudflare wanting to change their DoT key. They have
to get all their domain DS records updated. We can hope for CDS, but is
that realistic?

All of the draft (storing DoT signal plus pubkey in DS record) is
basically the same as storing this in a TLSA record at the nameserver
name, except it saves a few RTTs. But saving those RTTs is really not
that important if you do this at the large nameserver hosters, for which
a recursive presumbly already has a working DoT connection open because
it is serving so many more other domains.

It really makes much more sense to signal the capability of nameservers
with nameservers, and not with the domains they serve. Then if someone
uses ns0.nohats.ca, ns1.cloudflare.com and ns2.godaddy.com, those
hosters can all maintain their keys themselves and update their
nameservers without needing to inform or get consent from their millions
of domain name owners.


So we kind of concluded this was a neat hack, but we shouldn't really
think it leads to realistic at scale stable deployments.

Let's just use TLSA records on the nameservers. It is logically where
this information is authoritative for.

Paul and Viktor