Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Philip Homburg <pch-dnsop-1@u-1.phicoh.com> Tue, 10 January 2017 11:17 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D6129BAD for <dnsop@ietfa.amsl.com>; Tue, 10 Jan 2017 03:17:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCpn5n2a4MYN for <dnsop@ietfa.amsl.com>; Tue, 10 Jan 2017 03:17:50 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 495A8129B1B for <dnsop@ietf.org>; Tue, 10 Jan 2017 03:17:50 -0800 (PST)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cQuR2-0000FjC; Tue, 10 Jan 2017 12:17:48 +0100
Message-Id: <m1cQuR2-0000FjC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-1@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
In-reply-to: Your message of "Mon, 9 Jan 2017 23:38:14 GMT ." <201701092338.v09NcEqm059806@calcite.rhyolite.com>
Date: Tue, 10 Jan 2017 12:17:48 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gG4-rH5f8izJOBwn3uCjY3OZ9ro>
Cc: Vernon Schryver <vjs@rhyolite.com>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2017 11:17:53 -0000

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