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

Philip Homburg <pch-dnsop-1@u-1.phicoh.com> Mon, 09 January 2017 19:53 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 4C427129588 for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 11:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 FBvFnamWussp for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 11:53:39 -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 E6C9C129575 for <dnsop@ietf.org>; Mon, 9 Jan 2017 11:53:38 -0800 (PST)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cQg0e-0000CcC; Mon, 9 Jan 2017 20:53:36 +0100
Message-Id: <m1cQg0e-0000CcC@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
References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> <alpine.LRH.2.20.1701082342250.18316@bofh.nohats.ca> <F1E2DDCD-6114-43A3-B9FB-831C3AC13F15@fugue.com> <alpine.LRH.2.20.1701090959570.28120@bofh.nohats.ca>
In-reply-to: Your message of "Mon, 9 Jan 2017 10:14:27 -0500 (EST) ." <alpine.LRH.2.20.1701090959570.28120@bofh.nohats.ca>
Date: Mon, 09 Jan 2017 20:53:30 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ncYl2f42m40ipFiVx6T9ng6Fzlw>
Cc: Paul Wouters <paul@nohats.ca>
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: Mon, 09 Jan 2017 19:53:41 -0000

>See the recent discovery that Heathrow Airport runs a
>MITM TLS server on torproject.org. Do we want them to run RPZ where they
>can disappear torproject.org alltogether? No. Do we want them to run RPZ
>to prevent travelers from getting malware installed? Yes.

Just my crystal ball:
1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow
   Airport can mount a denial of service on DNS. So it does not matter if the
   malware zone is signed or not. If Heathrow Airport modifies the reply the
   traveler will be protected.
2) It makes sense to do local validation with something like getdns. If such a
   local validating resolver notices that DNSSEC validation fails ("Roadblock
   Avoidance") it may contact auth. DNS servers directly.
3) Heathrow Airport can move to deep packet inspection and also block
   direct access to malware DNS.
4) DNS is not really private so Google may offer their DNS services over HTTPS.
5) Governments may force Google to block popular sites, so users switch to
   other DNS resolvers, again over HTTPS.

After step 5, any benign malware filtering options are probably lost.

In that sense I don't care that much about the more philosophical arguments
arguments against rpz. If you care about DNS, run a local DNSSEC validating
resolver that does roadblock avoidance and possibly falls back to 
TLS or HTTPS to some trusted resolver.