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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
