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