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

From: Suzanne Woolf <[email-masked]>
Date: Tue, 18 Jul 2017 08:13:54 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 14:30:15 +0200

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 <[email-masked]>
wrote:

> 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.
>
> 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.
>
> 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.
>
>
> publication of the document as an independent submission or outside of the
> RFC series.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Petr Špaček <[email-masked]>
Date: Tue, 18 Jul 2017 14:32:36 +0200

> If you have a comment on this, please make it succinctly and soon.

I'm fine with Informational document describing the existing version of
RPZ. My hope that working on that as WG item will help to improve the
text so it is unambiguous. Improvements to the protocol can be done
later on.

-- 
Petr Špaček  @  CZ.NIC

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 18 Jul 2017 08:35:51 -0400

Hi,

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.

Suzanne

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 <[email-masked] 
> <mailto:[email-masked]>> 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:
>
>         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.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>
>
>

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 18 Jul 2017 08:41:13 -0400

Hi,

> text so it is unambiguous. Improvements to the protocol can be done
Thank you-- this is exactly the intent.

Suzanne

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 18 Jul 2017 14:42:01 +0200

If the WG still gets to freely edit the document while adhering to 
"describes an existing and widely deployed method", this seems like a 
good way forwards.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 14:42:56 +0200

Okay, sorry, that wasn't really clear.   Possible reading comprehension
problem on my part.   :]

On Tue, Jul 18, 2017 at 2:42 PM, Paul Hoffman <[email-masked]> wrote:

> "describes an existing and widely deployed method", this seems like a good
> way forwards.
>
> --Paul Hoffman
>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Jul 2017 10:46:11 -0400 (EDT)

On Tue, 18 Jul 2017, Suzanne Woolf wrote:

> If this is acceptable to the WG, we’ll keep the new draft with these changes as a WG draft. 

I'm okay with this approach.

Paul

---

From: avri doria <[email-masked]>
Date: Tue, 18 Jul 2017 23:35:12 +0200

>> If this is acceptable to the WG, we’ll keep the new draft with these

It is fine with me.

avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 19 Jul 2017 10:33:47 +0200

Hello Suzanne,

> If this is acceptable to the WG, we’ll keep the new draft with these 

Yes please!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2017 22:01:31 -0000

>"describes an existing and widely deployed method", this seems like a 

Text can change, bits can't.  OK with me.

R's,
John