Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla <[e-mail]>]

On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[e-mail]>
wrote:

> The idea of doing discovery in a new type of glue in the parent seems
> interesting. For the unauthenticated use case, it potentially removes a
> round trip, and doing so is quite valuable. If the WG likes the idea of
> new-glue-type-in-parent, Peter and I can add it to the draft covering
> unauthenticated ADoT to keep the two use cases in sync.
>
> Question: why does this draft use an SVCB record instead of a TLSA record
> for that new glue? The only advantage I see is that SVCB can indicate the
> DoH template, but the WG has so far not shown interest in DoH over DoT.


There are (at least) three reasons:
1. Semantically, TLSA does not mean "I support TLS", but rather "if you are
to do TLS, do it this way. SVCB means something different.
2. It's not clear that the certificate binding properties of TLSA are
desirable in the glue in this case, for a number of reasons, including the
"getting out of sync" problem that Ben Schwartz pointed out, and the
possibility that  we will want to use WebPKI.
2. SVCB does not just let you signal DoH versus DoT it also allows you to
signal DoQ, which has obvious advantages. In addition, if it becomes
necessary to signal what kind of credentials the server has. SVCB has a
natural way to add that.


A deeper question for the WG is the draft's elevation of unsigned records
> received in authenticated TLS as trustworthy. This WG has gone back and
> forth on this idea over the years, and I thought we ended up with no such
> elevation. If I'm wrong, or if the the WG shifts back to wanting that,
> that's great.


I don't think it's a matter of "trustworthy" or "untrustworthy", but rather
that if the referring server is untrustworthy than in many if not most
cases there will be marginal privacy benefit to establishing encrypted
transport. The reasons for this are laid out in the security considerations
(
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html#name-security-considerations)
but briefly  in a great number of cases the resolver just wants to resolve
the A/AAAA/CNAME for the child domain or a trivial subdomain (e.g., "www")
so (1) a malicious referring domain already has this information before it
even responds and (2) the malicious server can still lie about the unsigned
NS records, which one needs to use in order to get the signed NS records,
by which time you've again revealed the child name.

Peter and I could then make the draft that now covers just unauthenticated
> DNS actually be about opportunistic DNS (optional authentication).


I think trying to figure out what edits to make to which drafts is
premature. Let's first decide what we are trying to do and how.

-Ekr