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

[Robin Geuze <[e-mail]>]

Hello Paul,

I wanted to take a step back and explain the reasoning behind this 
implementation and why we didn't pick a different implementation.

So lets start at the beginning, why do we want to encrypt the 
communication between then resolvers and the authoritatives in the first 
place. There are two main reasons for encrypting things. One is 
authentication. DNSSEC already covers this aspect, at least in the sense 
of data authentication, it does not guarantee sender authenticity, I'll 
come back to this aspect later. One important aspect of the way DNSSEC 
works is that the parent zone is assumed to be trustworthy. We use that 
same assumption, since going around it would require a completely 
separate system, not unlike the CA system.

So the second reason to encrypt things is confidentiality. This is what 
the draft is meant to accomplish. Ideally this would mean we would get 
encryption all the way from the root to the eventual authoritative 
nameserver. This seems unlikely, so for this draft, and any other 
efforts to use DoT, we also need QNAME minimization to be used. To 
ensure confidentiality we need to ensure that the nameserver we are 
talking to is the actual nameserver we want to talk to. Like I said 
before DNSSEC does not offer that guarantee, primarily due to the fact 
that while DS records are signed in the parent zone, NS records are not, 
and thus can easily be spoofed by an attacker.

So we need some way to identify the nameservers we should talk to. 
Luckily we already have a mechanism for this, TLSA! So the simplest way 
to implement this would be to just put a TLSA record at 
_853._tcp.<nameserver>. There are a few problems with this approach 
though. Like I said before NS records are not to be trusted coming from 
the parent, this means that the TLSA record you get is initially not 
trustworthy either. You can establish the authenticity by requesting the 
NS records from the child as described in 
draft-huque-dnsop-ns-revalidation. This approach could work. But 
depending on the data you are trying to request it could lead to a 2 
times increase in queries at the very least, if you chain a bunch of 
nameservers that have yet more nameservers it at some point becomes 
problematic, because you need to request the TLSA record for each of 
them. And mind you, this slow down would be for all domains, not only 
those supporting DoT.

So a much cleaner, and more efficient sollution, would be to put a TLSA 
record for the specific domain somewhere. Ideally this would be in the 
parent zone, for example on a _dot label. However, that would mean that 
registry would need to implement a completely new concept, we would need 
a new EPP RFC, which knowing the average deployment time for new 
technologies by registries, would mean we would be done by the time hell 
is frozen over.

Another solution would be to put the TLSA record in the child zone. This 
could work, it would require only 2 additional queries (QNAME 
minimization remember). However, the downside is that your initial 
communication with the authoritative will still be plain text. You could 
solve this by putting a chain in the TLS handshake, however you would 
still need some way to signal that DoT should be attempted in the first 
place, otherwise resolvers would be wasting a lot of time probing which 
authoritatives support DoT.

So we are back to ideally signaling something via the parent. The only 
way to do this securely and without registries having to make large 
changes would be to use the DS record. The simplest way to accomplish 
this would be to just add a dummy DS record with an algorithm DoT. 
However, that still leaves the problem of getting some way to 
authenticate the sender. We could use the methods described above, 
however the problem of the initial communication remains. Stuffing the 
TLSA chain into the TLS Hello would solve that, but it would be a very 
complex solution to a simple problem.

This is where our idea comes from. “Hey, if we are going to be abusing 
the DS record anyway, why not put a hash of the key in there”. It is a 
simple solution, it will most likely be relatively easy to implement for 
registries (they only need to add a new algorithm number in some cases, 
the hashing method remains the same), and the amount of code needed in a 
DNSSEC resolver is minimal. It also requires no extra queries, which is 
a nice bonus.

So in summary, we think this solution is the simplest, and has the 
highest chance of deployment, due to it requiring minimal effort from 
all parties involved. Other solutions are definitely possible, however 
this is as far as I call tell the only one, outside TLSA records in the 
parent, that allows full start to finish encryption.

Regards,

Robin Geuze

On 03-06-2020 17:51, Paul Wouters wrote:
> 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
>