Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
Scott Schmit <i.grok@comcast.net> Sat, 07 January 2017 22:55 UTC
Return-Path: <i.grok@comcast.net>
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 08950129412 for <dnsop@ietfa.amsl.com>; Sat, 7 Jan 2017 14:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 GlpNrXU_rRJG for <dnsop@ietfa.amsl.com>; Sat, 7 Jan 2017 14:55:13 -0800 (PST)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C18C126BF7 for <dnsop@ietf.org>; Sat, 7 Jan 2017 14:55:13 -0800 (PST)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with SMTP id PztFcPURXRNZDPztIcHh1O; Sat, 07 Jan 2017 22:55:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483829712; bh=6O9e85AXWtlJRh/zVs/WbhkWx6VlU+b0diXHHpZyHV0=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=YFIjZwUEjR2sHSwPMw1K3AjaZOctVOHSYRFmH9CLzxOA/5xpDg++iJZCTEGT7QjOu hm/N4XGqWtmnUz8zDTNb/0waJIwA2/zimD9qi6Vgkj4B/cH9D5BhPDw5xb1jnlguGt LlaHGwm9eRd0P+DQti87rQ0HPBFgLL/3Yh2umh+XFiy56MgGSA64SeF2oMKThvsy6L NcvY6eUF3d+Z1SeyXKP6e0nFz/Qzq8EFPp76FNdkeLxbA8S8awehXrsgiE1KVTWr3a j9GglrdVV/CUo2fEwlc5e02TlwN47ILrthhhIJmG/AN8Xe06aVoNvmVO+I/bcMtlTH 0I+ZSaJ4JN9sQ==
Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-12v.sys.comcast.net with SMTP id Pzt5cjUZ2WEg6Pzt9c8Gsj; Sat, 07 Jan 2017 22:55:10 +0000
Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id v07MsvsT000858; Sat, 7 Jan 2017 17:54:57 -0500
Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id v07Msujn000857; Sat, 7 Jan 2017 17:54:56 -0500
Date: Sat, 07 Jan 2017 17:54:56 -0500
From: Scott Schmit <i.grok@comcast.net>
To: John Levine <johnl@taugh.com>
Message-ID: <20170107225456.GB10627@odin.ULTHAR.us>
References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="pf9I7BMVVzbSWLtt"
Content-Disposition: inline
In-Reply-To: <20161229163826.34758.qmail@ary.lan>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-CMAE-Envelope: MS4wfA+l7zKQlfLv6qYlrsp/XMyD682AgOMhOQ7btUnbbSvb7B4Op/Roe2xspLfT8BUa82zUxLSv4+ksRxw5F+tXaJu8m7+JQxtshK5MEBy6CYFi1FpqL9rc xGLm2O6x3tywWd5+U8pnqyd68r3nm/ecFmXGepfixsHxphmih9Bu6I3C
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4MKO1whQZtXAfzPXQyVWaSfHP5I>
Cc: dnsop@ietf.org
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: Sat, 07 Jan 2017 22:55:15 -0000
On Thu, Dec 29, 2016 at 04:38:26PM -0000, John Levine wrote: > >> Please see the previous gazillion messages from people who are using > >> RPZ in production to keep malware away from their users. > >> > >> Also see the previous gazillion messages noting that governments do > >> all sorts of DNS censorship now and don't need RPZ. > >> > >> Could you explain in more detail why you don't believe operators will > >> continue to use RPZ to protect their users, and why you think hostile > >> actors will do things with RPZ that they couldn't do now? > > > >I was specifically asking about the redirect/record replacement > >behavior, not the nxdomain/blocking behavior. > > Providers routinely use sandboxing to quarantine infected users both > to protect their other users (malware can't contact C&C) and to force > them to do something about it, since they can't see anything other > than web sites with cleanup tools. > > I've talked to providers who tell me that this is the least bad way > they've found to get their users to clean up infected boxes. Even if > a provider could afford to calli them on the phone, it doesn't work, > first because users not unreasonably think it's a scam, and second > because the malware doesn't bother them, only other people, so they > blow off advice to fix it. Thanks for explaining the use case. > So I reiterate the same two questions. Ok. > >> Could you explain in more detail why you don't believe operators will > >> continue to use RPZ to protect their users I believe you that RPZ is well-intentioned, and I'm sure that operators already using RPZ will continue to do so until it stops working or a better method is available. Eventually, if DNSSEC verification on endpoints becomes widespread, operators will need to turn to other means or break DNSSEC in these cases (but redirection will stop working). > >> why you think hostile actors will do things with RPZ that they > >> couldn't do now? For the very reasons that the authors want to make this an RFC -- RPZ isn't interoperable between DNS resolvers today. Once this RFC is published, it's clearly hoped that RPZ will be more interoperable and thus widespread. It's true that countries can legislate anything they want, and the publication (or not) of an RFC won't change that. But the enforcement of laws costs resources, and resources are finite -- so a country passing laws requiring network operators to filter and/or redirect will have no choice but to prioritize enforcement of such laws against other needs. There are already plenty of examples of countries limiting their enforcement of laws in recognition of implementation/enforcement costs. (For an example, see Richard Clayton's message on Dec 29.) If the implementation of laws is expensive, enforcement will also be expensive. If implementation of the law is cheap, enforcement is also much more cheap, and such laws consequently become more attractive. Having laws that cannot be effectively enforced on the books is certainly possible, but I suspect countries avoid it to maintain their credibility. RPZ being interoperable would appear to make implementation of filtering/redirection laws extremely cheap. Previously, the government would need to make a list of blocks and/or redirections and distribute that list to network operators in some fashion. By default, this would probably be via some kind of document which would then need to be translated into vendor-specific block/redirect lists. This is slow and expensive. Then, to enforce that these lists are being used, officials of the government would need to go around and check that the lists are being used and kept up to date. To do better, the government would need to define some kind of standardized format and get its use implemented. This isn't cheap either. If RPZ becomes interoperable (it doesn't matter if it's "standard", interoperability is standard enough), the government can just mandate use of RPZ and maintain the block lists directly. They can monitor that ISPs are consulting the RPZ in real-time, so enforcement is trivial. (Yes, the ISPs can query the list without enforcing it, but (a) information about what blocked domains are being accessed is useful and (b) that's no harder to check for, so it's irrelevant to the trade-off). Rich and highly-motivated governments will probably operate the same before and after RPZ becomes interoperable (though operating costs could go down, freeing resources for other programs or better enforcement), but other countries will find it easier to implement blocking and/or redirection in their country, increasing the motivation to do so. The blocking behaviors of RPZ will increase the load on networking infrastructure if the blocked addresses are DNSSEC-signed and endpoints validate the signatures. The redirection behavior of RPZ breaks in the face of DNSSEC validation if the records are signed, so it would be in the interests of a country that really wants the redirects to break all DNSSEC. Then the end user faces a choice: no DNSSEC or no Internet. They could try to use VPNs, but RPZ makes them easy to block nationally once discovered as well as easier to find users attempting to use them. (And if they're accessed by IP, that's even easier to block.) Setting aside how governments may choose to use RPZ, there are security risks to RPZ's deployment. Without RPZ, malicious actors that want to effect large-scale redirection of users would need to seek out the recursive resolvers of their endpoints and subvert them all. With RPZ, they only need to find the comparatively fewer RPZ servers and subvert them instead. If the location of the RPZ server is advertised (for accountability and network diagnostic purposes), then these addresses become available for malicious actors to seek out and attack. The redirection capabilities of RPZ are especially interesting to malicious actors, as they can become a means to take over a competing botnet's C&C network or redirect users to malware. If the location of the RPZ servers is hidden, diagnosing network problems becomes much more difficult. This has the net effect of making the DNS less reliable. The widespread use of captive portals has already made implementation of endpoint DNSSEC validation difficult and has essentially inhibited its implementation. I believe that widespread use of RPZ could do the same. All the above leads me to believe that RPZ is harmful to Internet security and infrastructure, however well-intentioned it may be. I do not support adoption of this draft. -- Scott Schmit
- [DNSOP] DNSOP Call for Adoption draft-vixie-dns-r… tjw ietf
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Suzanne Woolf
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ray Bellis
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Jim Reid
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Matthew Pounsett
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Allan Liska
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Hoffman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ray Bellis
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Tim Wicinski
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Hoffman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ray Bellis
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… bert hubert
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Hoffman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ray Bellis
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Hoffman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Warren Kumari
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ralf Weber
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… bert hubert
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… bert hubert
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… william manning
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- [DNSOP] Role of informational RFCs Re: DNSOP Call… Suzanne Woolf
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… sthaug
- Re: [DNSOP] Role of informational RFCs Re: DNSOP … Paul Hoffman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… sthaug
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Matthew Pounsett
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Matthew Pounsett
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Matthew Pounsett
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Viktor Dukhovni
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Mark Andrews
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Robert Edmonds
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Nolan Berry
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Stephane Bortzmeyer
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Stephane Bortzmeyer
- Re: [DNSOP] Role of informational RFCs Re: DNSOP … Stephane Bortzmeyer
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ralf Weber
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Patrik Wallstrom
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… John Levine
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Donald Eastlake
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Scott Schmit
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… John Levine
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Richard Clayton
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Scott Schmit
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… John Levine
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… william manning
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… joel jaeggli
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Viktor Dukhovni
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Warren Kumari
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Mukund Sivaraman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Warren Kumari
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Tony Finch
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… william manning
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Barry Raveendran Greene
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Scott Schmit
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Avri Doria
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Barry Raveendran Greene
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ted Lemon
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Philip Homburg
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… 神明達哉
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Viktor Dukhovni
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Philip Homburg
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ralf Weber
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Rich Kulawiec
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… tjw ietf
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Warren Kumari
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… joel jaeggli
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… william manning
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Ray Bellis
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Andrew Sullivan
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Suzanne Woolf
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Mukund Sivaraman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Wouters
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Paul Hoffman
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Petr Špaček
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Barry Raveendran Greene
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Viktor Dukhovni
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Melinda Shore
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Dave Crocker
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Doug Barton
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Mark Andrews
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Barry Raveendran Greene
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver
- Re: [DNSOP] DNSOP Call for Adoption draft-vixie-d… Vernon Schryver