On Fri, 29 May 2020, Peter van Dijk wrote:
On Wed, 2020-05-27 at 21:47 -0400, Ben Schwartz wrote: On Wed, May 27, 2020 at 9:27 PM Paul Wouters <[email protected]> wrote: Personally, I think it would be cleanest if we use the DS to signal the DoT nameserver only by FQDN.I agree. This is the design that I was attempting to describe. I see now that the chain extension doesn't have to be mandatory. A recursive that wants to use the extension can offer it. If it doesn't get a chain extension in the reply, it sends a TLSA query over the emphasis on: (as-yet-unauthenticated) TLS connection This means the TLSA query is subject to leakage by MITM. How bad that is depends on a bunch of things, but it is a wart.
The TLSA query is for the nameserver name, not the target domain name. Presumbly, by connecting to the IP of that nameserver, you have already revealed the information you are connecting to that nameserver, even if none of the traffic to that IP would provide any clue about the content. The privacy comes from many domain names being hosted by that nameserver, and not knowing which target domain you are going to query about. And ofcourse, thay only works if the A/AAAA records you get back go to another IP address used by many other domain names (and no SNI leakage). In the end, the protection from recursive to auth is not gaining us that much privacy, especially compared to stub to recursive. I think what does help us is if we break the one to one relationship between packets from stub to resolvers and from resolvers to auth servers. But that should probably be written up in another draft document, by someone with a PhD in statistics :) Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
