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

Richard Clayton <richard@highwayman.com> Thu, 29 December 2016 12:44 UTC

Return-Path: <richard@highwayman.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 D01F61295B8 for <dnsop@ietfa.amsl.com>; Thu, 29 Dec 2016 04:44:55 -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 SZp3GWeqGqKW for <dnsop@ietfa.amsl.com>; Thu, 29 Dec 2016 04:44:54 -0800 (PST)
Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (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 16129129548 for <dnsop@ietf.org>; Thu, 29 Dec 2016 04:44:53 -0800 (PST)
Received: from localhost ([127.0.0.1]:46759 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.88) (envelope-from <richard@highwayman.com>) id 1cMa4h-000Esa-J3 for dnsop@ietf.org; Thu, 29 Dec 2016 12:44:51 +0000
Message-ID: <kHKKXtEjTQZYFAGI@highwayman.com>
Date: Thu, 29 Dec 2016 12:43:15 +0000
To: dnsop@ietf.org
From: Richard Clayton <richard@highwayman.com>
References: <20161229040637.GA26031@odin.ulthar.us> <20161229054559.31443.qmail@ary.lan>
In-Reply-To: <20161229054559.31443.qmail@ary.lan>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <q+6$+vhm77vawNKLAjd+d626Yz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QwYSZHP-DzVPxKuTLOeFGqx_rXg>
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: Thu, 29 Dec 2016 12:44:56 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <20161229054559.31443.qmail@ary.lan>, John Levine
<johnl@taugh.com> writes

>>I'm seeing how it really helps governments cheaply create and enforce
>>the creation of national internets -- especially with the walled garden
>>features.  Are those the good guys to you, or are there other benefits?
>
>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.

Much DNS censorship in the UK (regimes vary) is only implemented by the
largest ISPs because only they have been able to find the necessary
engineering time (when you operate at scale it's not just about setting
a config option...)

The UK Government (who pressurise the ISPs to block child sexual abuse
images, some file sharing sites and who have grandiose plans to have a
centralised list of malware URLs) tends to be happy because 5 ISPs
covers about 95% of the population...

Everyone involved understands that there isn't at present a turnkey
application that the other 5% (and indeed all the in-house corporate
systems) could deploy.... so this also makes the people who don't want
the Government messing with their DNS results happy as well because
anyone who rolls their own system pretty much opts out.

>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 can foresee Governments taking IETF standardisation of RPZ (that will
be their words) as a way of pressurising those who have not yet deployed
it to do so -- using lists supplied by them.

So although deploying RPZ does a reasonable job of papering over the
cracks in our response to cybercrime I think that on balance it's too
dangerous a tool for the IETF to wish to bless in any way -- it's poor
social hygiene to standardise these types of tools.

I also note from reading the draft that this blessing will freeze in
some rather ugly design (with the authors arguing that the installed
base cannot adjust to something cleaner). If the IETF must do anything
in this space then documenting an interchange standard for DNS related
badness (with annotations to hint at how this badness might affect a
resolver) would seem better engineering and rather less dangerous.

- -- 
Dr Richard Clayton                               <richard.clayton@cl.cam.ac.uk>
Director, Cambridge Cybercrime Centre                mobile: +44 (0)7887 794090
Computer Laboratory, University of Cambridge, CB3 0FD   tel: +44 (0)1223 763570

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBWGUE4zu8z1Kouez7EQJolQCePA1xB5kCbsbYHxWR5x/yBgRyT8kAn2EW
JhXwn3xxerk+TDrhV3PftL/P
=NInm
-----END PGP SIGNATURE-----