>Then you have a problem that's not solvable in DNS itself (yet). That's >what people usually forget to consider. > >The hostnames are clear-text in https hanshakes (so far), and it seems >relatively easy to collect those. So, by tunneling *only* DNS you don't >make it much more difficult for the ISP, and in addition you share the >names with some other party. That doesn't sound very appealing to me >personally, from privacy point of view at least. (On the other hand, >big resolvers will have lots of cached answers, etc.)
This is too some extent a chicken and egg problem. Without encrypted DNS there is no point in encrypted SNI and vice versa. I expect that encrypted SNI will be relatively easy to deploy. It can happen as soon as both endpoints support it. In contrast, DNS is a very complex eco system. So it makes sense to start deploying encrypted DNS now, under the assumption that encrypted SNI will follow. >After SNI encryption gets widely deployed, tracking through IP addresses >only will be somewhat harder, so there it will start getting >interesting. We have seen already that 'domain fronting' is can be a very effective way to bypass filters. For large CDNs or cloud providers, filtering based on IP addresses is not going to be effective. >Until then, IMHO you just need to either trust the ISP or >tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted >party. True. But we can take small steps to reduce unwanted interference from ISPs. >From a security point of view, it helps a lot if you can just trust DNS. Instead of always having to take into account that somebody may interfere with DNS replies.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
