>> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathro
>w
>
>>4) DNS is not really private so Google may offer their DNS services over HTTP
>S
>> 5) Governments may force Google to block popular sites, so users switch to
>>    other DNS resolvers, again over HTTPS.
>
>See https://developers.google.com/speed/public-dns/docs/dns-over-https
>but I don't know how clients bootstrap that API without classic DNS.

The nice this about Google is that they are too big to block.

It is not a problem to use plaintext DNS to connect to Google because the
CA system and possibly DANE will protect the TLS connection.

>block child porn, drug, terrorist, and malware web pages as well as
>attempts by corrupted laptops and smart phones to bypass blocks on
>port 53 and reach evil or merely unfiltered DNS/HTTPS servers including
>those run by Google?

I'm not sure what 'HTTPS proxy' means in this context. If a public wifi
at an airport can decode TLS traffic then we have a serious security hole.
(Of course SNI is a problem. Hopefully TLS 1.3 will improve that)

But the bigger problem is that most users don't really care about the
difference between a public wifi operated by an airport and a public wifi
operated by a criminal. And maybe the criminal just took over the wifi
router at a respectable restaurant.

So an ISP can null route traffic to known bad destinations (though people
may switch to TOR to even deny an ISP even that option) but anything that
goes beyond that (ISP access to DNS, etc) also provides great opportunities
to attackers.

It doesn't really help much if an airport blocks malware but the bar next door
doesn't.  So for any mobile device, you have to secure the device anyhow.
Then this extra protection by ISP mostly becomes another attack vector.

So at least for mobile devices it makes sense to make sure that all 
traffic on the wifi interface is encrypted and we keep the ISP out of the
loop as much as possible.


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to