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]

[Paul Wouters <[e-mail]>]

On Tue, 9 Jun 2020, Robin Geuze wrote:

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

I disagree. Setting up a TLS connection to a trusted source for DNS data
does not mean I want or should need to blindly trust that source. DNSSEC
(origin authenticity) is orthogonal to transport security. Setting up
DoT - especially between recursive and authoratative DNS servers has
nothing to do with authentication. For that, we can only rely on DNSSEC.

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

I agree.

> So the second reason to encrypt things is confidentiality.

That is the only reason. The document Introduction Section also really
only mentions "no protection against snooping".

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

I agree.


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

The draft does not actually do this, because it does not verify at the
child that the parent didn't make up the special DS record (See my MAY
vs MUST disussion)

> So we need some way to identify the nameservers we should talk to.

If you trust the parent TLSA connection and the parent to produce the right
content, then you do identify the nameservers already despite its lack
of RRSIGs, if you connected to that parent securely (and privately).
If you do not trust the parent, they can just give you any DS record they
want, pointing to their own (or their government's) DoT servers.


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

This is incorrect. The TLSA lookup of the _nameserver_ name is
independent of the lookup of the _domain_ you are doing, for which
you get the (unsigned) NS records. So the TLSA record is trusted. What
you meant to say is the NS glue records are untrusted, and I agree.
But they are just as untrusted as the DS record, because it is the
same entity publishing them - the parent. And we assume we have a secure
and authenticated and private connection to that parent.

Sure, you can (MAY or MUST) confirm the DS record with a child's CDS
record, but unfortunately doing that query is where you would leak
the domain name you are trying to hide when talking to this target
nameserver over DoT via the special DS record. So that does not help
you against a malicious parent. So you might as well trust the unsigned
NS and signed DS records.

> You can establish the authenticity 
> by requesting the NS records from the child as described in 
> draft-huque-dnsop-ns-revalidation.

An attacker might not be able to give a false answer, but they don't
need to. They just needed your query for you to lose your privacy.
If you query for any child zone information at what you _think_ is the
nameserver, you have leaked that information to that nameserver
operator. Even if it is the wrong one.

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

My argument against the drafts focus on reducing RTTs was that if you
are making these queries to nameservers serving so few domains that you
do not have those TLSA nameserver records cached, that those nameservers
are serving so few domains that just revealing that you connect to them
reveals the small set of domains hosted there already. You can super
privately connect to ns0.nohats.ca, but there are only 50 domains hosted
there.  It's pretty easy to figure out which one you were going for.

If the domain is at cloudflare, dreamhost, google, amazon, etc, then
those TLSA record queries you would need to do for the nameserver names
are a cost you incur once, and with proper pre-fetching (as for example
implemented with unbound) you would never incur a delaying cost again
after resolving the first domain's DoT nameserver TLSA record. The next
tens of thousands or millions of domains that use that same nameserver
TLSA record require 0 RTT lookups.

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

I agree with this (except for the much cleaner and more efficient parts)

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

This would not work. Querying for TLSA records in the child zone already
reveals the domain you are interested in. If you are still on an
unauthenticated (but private) DoT channel, you cannot send any query
that would reveal the target domain name.

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

It is not a "lot of time" for the larger domain hosters which are the
only places where you could hide within the large domain crowds for
anonymity. See above.

> So we are back to ideally signaling something via the parent.

This is the premise I disagree with. And without this premise, this
draft is only about shaving off 1 or 2 RTTs of super large scale
nameservers, and that goal is (in my personal opinion) not worth the
hassle for squaring a round bit of information in a square DS record.

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

A TLSA record on the nameserver for DoT is simper, and does not need any
RFC so it has a higher chance of deployment.


And another point you don't take into consideration is the previous MAY
vs MUST discussion. To prevent a country wide DoT Firewall being rolled
out by a TLD inserting rogue DS records pointing to their national DoT
firewall, you would have to confirm the DS record at the child. So while
your proposal might win 1 or 2 RTTs, to do it securely, you lose at
least 1 RTT to verify that DS record from the parent at the child.

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

Again, you are not making explicit that it is possible using TLSA
records at the nameserver locations as well, except that you don't
like the additional RTTs.

On top of that, you need special support at Registry and Registrar
level for getting "bogus" DS records accepted (via EPP, CDS/CDNSKEY or
registrar/registry webgui. This on its own will prevent wide spread
adoption of this document. Then you have the cases where people spread
their nameserves over different providers, and they will use different
DoT public keys. Imagine being cloudflare and 50 million domains have
DoT public keys in DS records at their parents. As long as one domain
did not update, they cannot update their TLS key on the DoT server.
In reality, they will never be able to change the private key of their
DoT servers. If the public key lives on ns0.cloudflare.com, they can
go ahead and update this whenever it is needed. They just need to update
their own TLSA record.

The TLSA at nameserver solution requires no EPP, no RFC, no synchronization
between nameserver operators or between registries and nameserver
operators and can be implemented right now.

I also initially thought this was a cool idea and worth doing. But as I
said in my email mentioning my discussion with Viktor, we realised
the cost of the complexity added to save perhaps 1RTT are going to
prevent this from being deployable at scale. And without scale, you
don't get the anonymity DoT can provide.

Paul