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

Paul Wouters <paul@nohats.ca> Sun, 01 January 2017 18:20 UTC

Return-Path: <paul@nohats.ca>
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 36D10129455 for <dnsop@ietfa.amsl.com>; Sun, 1 Jan 2017 10:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 CnQwC1amyGmC for <dnsop@ietfa.amsl.com>; Sun, 1 Jan 2017 10:20:23 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9DEBD129448 for <dnsop@ietf.org>; Sun, 1 Jan 2017 10:20:23 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ts7mM4wrjz3Wp for <dnsop@ietf.org>; Sun, 1 Jan 2017 19:20:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483294819; bh=qVmH2kI1V7hMJebp9QNVVEU59+vvFti1s9iGwnsONx8=; h=Date:From:To:Subject:In-Reply-To:References; b=txHN7Z16xJJQ5FJ/l3/Mmu/Q6BsHn8C+MsuPEfJzH6nwBNzouI2oKtmebBtii67V/ jBjhkgPgN7RQcsdQzHM06BsHHTdzSnGXuOy31o+1hCCNxoWJKo4xH2XV1E7nyqwsuT UcwUS3Ycb7/pQlv3G8Ab3PRgNBE7OjVu2HHubmrg=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Ax2hIDCKVeb8 for <dnsop@ietf.org>; Sun, 1 Jan 2017 19:20:17 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Sun, 1 Jan 2017 19:20:16 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id A3810CA34A4; Sun, 1 Jan 2017 13:20:14 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A3810CA34A4
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CCDF4942C63 for <dnsop@ietf.org>; Sun, 1 Jan 2017 13:20:14 -0500 (EST)
Date: Sun, 1 Jan 2017 13:20:14 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com>
Message-ID: <alpine.LRH.2.20.1701011313510.23906@bofh.nohats.ca>
References: <20161229040637.GA26031@odin.ulthar.us> <20161229054559.31443.qmail@ary.lan> <20161231202731.GX13486@mournblade.imrryr.org> <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AJ5jSGhxtgAHqXPPbmJ9O4N0aAw>
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: Sun, 01 Jan 2017 18:20:26 -0000

On Sat, 31 Dec 2016, Ted Lemon wrote:

> There is no _way_ to make it easier for said outside forces to pressure providers.   They have the force
> of law on their side.   What we do makes no difference in that arena.   The arena in which it _does_
> make a difference is protecting people from losing their homes because they got suckered by some malware
> that got into their personal records on their computer.
>
> IOW, the argument you are presenting has nothing to do with the choice that faces us.   If you want to
> make the case for rpz being a bad thing, the argument you should be making would have to show why
> protecting people in this way is the wrong solution to the problem, and why some other solution to the
> problem (e.g., a blacklist in the browser) is less bad.
>
> Can’t we have that conversation, instead of these repeated assertions about things over which we have no
> control?

Some of us tried that and were told "that's not how RPZ works, we are
not changing how RPZ works".

The only thing I asked for is tracability and accountability, but not
witholding DNSSEC information but by passing it along in a different
section so that:

- RPZ still works as it does now for existing users/providers

- In the future RPZ filtering cannot be used as an out-of-the-box
   involuntary censorship tool.

- Accountability can be added by adding a different key of last
   mile trust anchor.

I'm interested in hearing technical reasons why this change cannot be
done, and lacking those, I would hope the WG does not adopt this document
if the authors are unwilling to make the changes to facilitate this..

Paul