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

[Paul Hoffman <[e-mail]>]

On Feb 25, 2021, at 12:44 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[e-mail] <mailto:[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.

Fair point. However, given that we get to say what a particular usage of a particular RRtype is, that is not fatal.

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

OK. From the wording about authentication in the draft, I figured you would actually want DNS-based public keys, even with the general problem of TLSA and getting out of sync.

> 2. SVCB does not just let you signal DoH versus DoT it also allows you to signal DoQ, which has obvious advantages.

TLSA also lets you signal DoQ. If it didn't, we would have rejected it out of hand.

> In addition, if it becomes necessary to signal what kind of credentials the server has. SVCB has a natural way to add that.

Well, you said that in your draft, but I don't see that as a possibility in Ben's draft. It could be added, but there is no extension mechanism there.

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

That's a better phrasing than my shorthand; agreed.

> 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 [ekr.github.io] <https://urldefense.com/v3/__https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html*name-security-considerations__;Iw!!PtGJab4!tX921UZjQGXS55wAOrtbw-opH3qkVrpzieoyLjMLPdY_GagY8gv6l_AiQsvIvAIoiUYWx7ldTQ$>) 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.

That, plus the encrypted channel prevents malicious record substitution.

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

Both can happen at the same time.

--Paul Hoffman