On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[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. 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
