Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

"John Levine" <johnl@taugh.com> Thu, 22 December 2016 17:59 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 C86DD1296CB for <dnsop@ietfa.amsl.com>; Thu, 22 Dec 2016 09:59: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 IC7s9sS8BjlW for <dnsop@ietfa.amsl.com>; Thu, 22 Dec 2016 09:59: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 69962129670 for <dnsop@ietf.org>; Thu, 22 Dec 2016 09:59:49 -0800 (PST)
Received: (qmail 60465 invoked from network); 22 Dec 2016 17:59:52 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Dec 2016 17:59:52 -0000
Date: Thu, 22 Dec 2016 17:59:24 -0000
Message-ID: <20161222175924.4959.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <201612221536.uBMFacG2039081@calcite.rhyolite.com>
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/eMqR_uALr06B-C7NWDL_ZMW8Jz0>
Cc: vjs@rhyolite.com
Subject: Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt
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, 22 Dec 2016 17:59:51 -0000

>> Protocol signalling can help, but it is a relatively trivial matter
>> compared to how the blocking technology is explained to the people who are
>> affected by it.
>
>I don't agree.  While my Aunt Mildred might understand the instructions
>of a walled garden the next time she infects her computer, she'll never
>understand RPZ, HTTPS proxies, or even firewalls.  Even if she had the
>wit, she lacks the interest.

Users do strange things.  People at large mail systems tell me that
their users constantly take obvious phishes and 419s out of the spam
folder and respond to them, so the mail operators do things like
rewriting the mail to make the links unclickable even if it's
moved back into the inbox.

If we make a mutant RPZ that signals when something's rewritten, I can
promise that some clever person who imagines that RPZ is 99%
censorship and 1% anti-malware, rather than the reality which is the
other way around, will write a "free speech resolver" that undoes the
changes so the malware goes straight into the user's browser.  Then,
of course, the users will blame us for not protecting them from
cryptolocker.

As many people have pointed out, censorship happens with or without
RPZ, and it is pure hubris to imagine that anything we do or don't do
with RPZ will change that.  On the other hand, we've seen plenty of
reports from operators with actual experience of RPZ protecting their
users from malware.  So let's do something pro-user for a change.

R's,
John