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

[Brian Dickson <[e-mail]>]

On Wed, Jun 10, 2020 at 12:29 PM John Levine <[e-mail]> wrote:

> In article <CAH1iCir5KaEr6JU5exF7VRQ2yYe6xZ-cLmwmXg3yM=
> [e-mail]> you write:
> >That leaks information to an attacker ONLY if the attacker has
> successfully
> >caused the resolver to get the wrong NS name at the first step.
> >
> >There is a method for preventing that: if the delegating name server (e.g.
> >TLD) supports DNS-over-TLS-to-Authority (DoTA), and the resolver obtains
> >the unsigned NS over a TLS connection. ...
>
> Right.  We have to bootstrap somehow and this seems about as good as we
> can ask for.
>
> >The details involved in getting the TLSA record for the NS name are left
> as
> >an exercise for the reader (but are easy enough to figure out, they're
> >literally an exercise in 4033/4034/4035.)
>

I wrote "getting" meaning "querying/validating", not setting.


>
> The principle is easy. What's hard is the Provisioning Crudware(TM)
> that will have to be updated to handle TLSA glue. You might see this
> as a dealbreaker, with the alternative being to abuse DS or some other
> record that we hope the Crudware already handles.
>
>
No, this isn't TLSA glue... this is TLSA below the delegation point for the
authority server's zone (which is serving the NS name and has the TLSA
records for all those NS names).
It's TLSA on the child side of the delegation, which depends on either
trusting, or validating (somehow) the NS record for the delegation for the
zone owner's domain to the providers name server(s).
The TLSA record is for a name which is not subordinate to the zone owner's
domain, it is for a name operated by the DNS provider.

I.e. that is stuff the DNS provider is responsible for, and does not
require the zone owner to deal with.
The zone owner points at the right NS, and other than the initial DS
record, doesn't need to do anything else.


> >(The reason for this is mostly about how EPP handles host records needed
> >for maintaining TLD glue, and scalability of management of all of that.)
>
> See above.  It's not just EPP, it's the provisioning system for any DNS
> server
> that delegates a subtree to another server.
>

The presumption I make is that there is nothing to add for provisioning
this... it is literally piggy-backing on the NS, for getting the name used
for the TLS connection, and getting the corresponding TLSA record.
This still does have the problem to solve, for "protecting" the NS name
which is not signed.
The options I can think of there are DoTA to the TLD, or AXFR with TSIG or
ZONEMD, or direct queries with TSIG to the TLD.
None of these is scalable or nice, and the TSIG one requires de-anonymizing
the recursive operator, or at least registering specific TSIG keys via
unspecified anonymous/pseudonymous methods.

Brian