On Feb 25, 2021, at 12:44 PM, Eric Rescorla <[email protected]> wrote: > > > > On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[email protected] > <mailto:[email protected]>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
