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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 21 December 2016 20:01 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 2CCEB129430 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 12:01:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 YbD1Et-JROSb for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 12:01:16 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3161295A6 for <dnsop@ietf.org>; Wed, 21 Dec 2016 12:01:05 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E804A284DEF; Wed, 21 Dec 2016 20:01:04 +0000 (UTC)
Date: Wed, 21 Dec 2016 20:01:04 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20161221200104.GK13486@mournblade.imrryr.org>
References: <C18E2D4E-EE89-4AF6-B4A0-FAD1A7A01B5E@vpnc.org> <5248A099-7E1F-437A-A1B7-C300F917D273@fl1ger.de> <CACfw2hj4VfuqsM-jRpxNc+bWNsUcSid+Y=r9U5jsA-0ZLbLRUg@mail.gmail.com> <20161221.163826.74705202.sthaug@nethelp.no> <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca> <CAAiTEH_-LGUkpmPjDRsKpnPhXev1sNdF_2yaVXKmeWMJ7vm_eg@mail.gmail.com> <6C982A3A-721C-4094-A04F-059698581321@fugue.com> <CAAiTEH_LOUhCSRuDNggTK9f1iWw6dCQB2bJQ7FVyYn3MH49KUQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAiTEH_LOUhCSRuDNggTK9f1iWw6dCQB2bJQ7FVyYn3MH49KUQ@mail.gmail.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5GqlW5N4fYiKg2i9q2b2-B1sLWQ>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dnsop@ietf.org
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: Wed, 21 Dec 2016 20:01:18 -0000

On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote:

> RPZ is not the ideal, but it works, and goes beyond being deployable–it is
> deployed.

I am curious to understand how RPZ zone transfers are (intended to
be) secured.  It sounds like the reason for standardizing RPZ is
to allow interoperable sharing of policies via replication of zone
data, and so an appropriate security mechanism would seem to be
desirable here to authenticate the transfer of data from the RPZ
master zone.  Is there a related specification for that?

As a (long-ago) emigre from the then Soviet Union, I am loathe to
see the IETF standardizing scalable censorship mechanisms, however
well intentioned.  Let's hope that skepticism of such "progress"
can evolve without the personal experience of having lived under
a totalitarian regime.

Once the infrastructure that RPZ makes possible is deployed at
scale, it will surely become increasingly difficult to bypass.
This proposal is a major step towards building the Great Firewall
of <your CountryName>, and should I believe be resisted.

-- 
	Viktor.