Re: [DNSOP] draft-ietf-dnsop-dns-rpz

Suzanne Woolf <> Tue, 18 July 2017 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4F45131E0B for <>; Tue, 18 Jul 2017 05:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aZ9yk-14TqEY for <>; Tue, 18 Jul 2017 05:35:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9167131DE8 for <>; Tue, 18 Jul 2017 05:35:55 -0700 (PDT)
Received: by with SMTP id w4so26898536wrb.2 for <>; Tue, 18 Jul 2017 05:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=zaUL86XZRIqc5KAEh3ylJz4N+xjemza6FRoHd2/D/ew=; b=WVPU9do5cIP8Yy8JJl06UyGWC6TO8oqreJXsW4fJm5emPGLBs00ii6GO3nx+2i7FVf 4n6FPZ1J4GHP6NjzWZiP8yBNPfsiyv81JaIqEA3bg6sWnrikdQY+t8wKtVSzSp+SkP3Q Px+CPqzQ+4muIUy4DBEyp6Wd9XNd9xXDb5pmu1sS0bQE+DMa+XIKCR/W20DaMNekbsbT aLOEjAr8YrIAeC9OkY/HIyTdVks4++N36xwTiVFae1LvB8zvfQPHjPIpdkfFDTLR+38d 8tQvVMjYA2hUvaXZ4Hlxrw9oGLxOeChpwA6BUHci/WoNRbGvyeTA08XMF9tLfokOyPUj a1Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zaUL86XZRIqc5KAEh3ylJz4N+xjemza6FRoHd2/D/ew=; b=nJDSB1pOeyDyDKJKUYvbcX5zeS//cwVcgAq7/TpWzLHZeZ48STf8D4724ILJZnD/6D 7QiJ/zGI3A72A5Jk22hsNYd7pb+djMosUNOwoFmcHXypzu/+5N/qomOywM+7JDy6E1u6 rvNMclaKvT3s4i4hwFuNDq5uqwfCVKCj9i4bgCxx3OV0AuIymdb7OjhrHyGX5qJ/CbFB HpLypRFK9XlgpbDNdY5t/4Xou9SMbkwEnAZvvH3gWKBf4ywIMjAz0wMYp4sn3QnwIkPO dk0XIpuWbrEQ1RTK9QV4YNSC1jCd82vc9w/AnoWj8ETV4UP4r+q5rMLQK0GtpoQXJ8TZ baAw==
X-Gm-Message-State: AIVw113PQk2jisAMVIu3OBAM4fMJtWneaqgIFhba4PHJ9Bp29xAU8x8i A+OTjwxTBbpkzekkFzo=
X-Received: by with SMTP id e126mr1653244wmd.107.1500381353577; Tue, 18 Jul 2017 05:35:53 -0700 (PDT)
Received: from ([2001:67c:370:128:2c3e:2bed:84a7:da01]) by with ESMTPSA id i136sm13128809wmf.33.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:35:52 -0700 (PDT)
References: <> <>
From: Suzanne Woolf <>
Message-ID: <>
Date: Tue, 18 Jul 2017 08:35:51 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1A78F7133EE5704309F9785B"
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 12:35:58 -0000


The working group does get to work on it. The specific suggested wording 
was about the scope of the document, which the chairs felt was 
consistent with what the WG had already decided about the document: that 
they were willing to work on it as an Informational description of the 
existing protocol.

This is why the original boilerplate wasn't acceptable for a WG 
document, and the authors have agreed to change it in order for it to be 
kept as a WG document.


On 7/18/17 8:30 AM, Ted Lemon wrote:
> If the working group doesn't get to work on it, it seems more 
> appropriate to publish it as an ISE document.   This is what has been 
> done in similar cases in the past.
> On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woolf < 
> <>> wrote:
>     Dear colleagues,
>     As you might recall, we had a call for adoption
>     for draft-vixie-dns-rpz just before IETF 98 in March. We had a
>     lively discussion and decided to adopt the document for further
>     work in the WG as an Informational RFC.
>     However, the chairs then discovered we’d made a mistake in
>     adopting the draft with the copyright that reserved rights in
>     derivative works to the original authors. This isn’t allowed for a
>     Working Group document (see RFC5378, Section 3.3).
>     We’ve talked since then with the authors about how we might move
>     forward with the draft. They had concerns, which had already been
>     discussed on the list, about some of the views of the WG on the
>     applicability of RPZ.
>     We believe we’ve found a way forward that meets their concerns and
>     the needs of the WG. We propose that:
>     1. The draft adopts the following language in the Introduction:
>         This document describes an existing and widely deployed method
>         by which a security policy can be applied to DNS responses,
>         possibly causing an end system to receive responses that do
>         not correspond to actual DNS zone content. Such policy-based
>         responses might prevent access to selected HTTP servers, or
>         redirect users to "walled gardens", or block objectionable
>         email, or otherwise defend against DNS content deemed
>         malicious by the RDNS operator and the end-user.
>         This method describes its policy using a specially formatted
>         DNS Zone called a Response Policy Zone (RPZ), and is an
>         instance of a more general mechanism called a "DNS Firewall."
>         Like other mechanisms called "firewalls," response policy
>         zones (RPZ) can be used to block both wanted as well as
>         unwanted data.  RPZ ought not be used to interfere with data
>         desired by recipients. In other words, RPZ should be deployed
>         only with the permission of every affected RDNS end-users.
>         This document does not recommend the use of RPZ in any
>         particular situation or instead of other mechanisms including
>         those more commonly called "firewalls."  This document lacks
>         an applicability statement for that reason, and because it
>         merely describes a currently common practice, without
>         recommending or criticising that practice. By design and
>         expectation, response policy zones (RPZ) must be seen as a
>         defensive and virtuous tool, or it will either not be used, or
>         will be bypassed by end-users.
>     2. We had already limited the the scope of the document to
>     describing the current protocol, with any discussion of proposed
>     changes left to a later document if people want to do that work.
>     That limitation stands. The intended document status is Informational.
>     3. The copyright is changed to the standard boilerplate required
>     for a WG draft.
>     If this is acceptable to the WG, we’ll keep the new draft with
>     these changes as a WG draft.
>     If not, the draft will be dropped as a WG item. The authors can
>     seek publication of the document as an independent submission or
>     outside of the RFC series.
>     If you have a comment on this, please make it succinctly and soon.
>     thanks,
>     Suzanne & TIm
>     _______________________________________________
>     DNSOP mailing list
> <>
>     <>
> _______________________________________________
> DNSOP mailing list