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

"John Levine" <johnl@taugh.com> Thu, 29 December 2016 16:38 UTC

Return-Path: <johnl@taugh.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 A57E812952C for <dnsop@ietfa.amsl.com>; Thu, 29 Dec 2016 08:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 K8wY4SCu3Nbl for <dnsop@ietfa.amsl.com>; Thu, 29 Dec 2016 08:38:49 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880AA1293F3 for <dnsop@ietf.org>; Thu, 29 Dec 2016 08:38:49 -0800 (PST)
Received: (qmail 71214 invoked from network); 29 Dec 2016 16:38:54 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Dec 2016 16:38:54 -0000
Date: 29 Dec 2016 16:38:26 -0000
Message-ID: <20161229163826.34758.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <20161229160603.GA10627@odin.ULTHAR.us>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GyhpUNeBoll_Vqfo1PLhgUyUtU8>
Cc: i.grok@comcast.net
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 16:38:50 -0000

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

So I reiterate the same two questions.

R's,
John