Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Philip Homburg <[e-mail]>]

>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.