> The privacy concern DPRIV is trying to address is to prevent an adversary > seeing the contents > of DNS traffic or being able to deduce them from packet sizes, timing etc. > > That is a very different problem from stopping the attacker from being able > to distinguish > DNS traffic from HTTP. At the extreme, any client connecting to 8.8.8.8 is > doing DNS...
OK. So, we have clarified that you do not have an issue with leaking SNI while using TLS for DPRIVE. You are looking at ways to plug the SNI leak in TLS, and also the clear text certificate leak. You are concerned that even if make DNS traffic opaque, adversaries will still be able to retrieve the same information by harvesting SNI and certificate. That's certainly a valid concern, but why not fight one battle at a time? Let's first make DNS traffic opaque. That's the DPRIVE charter. Then plug the holes in TLS. That ought to be the TLS charter. The circular dependency that you hypothesize is only an issue if SNI+CERT disclosure mitigations (1) need to be applied to the DNS resolver connection and (2) require finding data in DNS. I am not sure at all about (1) since as you wrote, "at the extreme, any client connecting to 8.8.8.8 is doing DNS..." And I would rather not assume that the data comes from the DNS as in (2), before seeing actual designs... -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
