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

Petr Špaček <petr.spacek@nic.cz> Fri, 06 October 2017 13:56 UTC

Return-Path: <petr.spacek@nic.cz>
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 6B1061349CC for <dnsop@ietfa.amsl.com>; Fri, 6 Oct 2017 06:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 xWtckY0-DwXR for <dnsop@ietfa.amsl.com>; Fri, 6 Oct 2017 06:56:24 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 0EF3C1349C8 for <dnsop@ietf.org>; Fri, 6 Oct 2017 06:56:23 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:bc7e:ccff:fea4:1d71] (unknown [IPv6:2001:1488:fffe:6:bc7e:ccff:fea4:1d71]) by mail.nic.cz (Postfix) with ESMTPSA id 0EDEE61109 for <dnsop@ietf.org>; Fri, 6 Oct 2017 15:56:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1507298181; bh=mjws3+d/HrZQ1nYOMsfev2rTfdgvrW5IKDsglcqR71k=; h=To:From:Date; b=X/cHYKgFEX3vTy+kmHyGwV4IPvuXVOuNzOQ58gIzTyjUoliz8LR38GE+mteOKRvpO gwdX0jqqOHmHTa/Ea0+q/XlWOk2cdy75VozGtDH4uvKiKN6XdeyuTG5epLyi0xW8wh Q1dFjnQGhRnA1VS0xCkrtNoFKELIMJj1R8Koj9EM=
To: dnsop@ietf.org
References: <d7dd539d-e2b9-b708-cc7e-8b417ff06a20@gmail.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <a1c456fd-8d80-4e61-56d1-2ee05ea3eeef@nic.cz>
Date: Fri, 06 Oct 2017 15:56:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <d7dd539d-e2b9-b708-cc7e-8b417ff06a20@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NoOg44k7LuK4k9XV4bbGZTtroLw>
Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 06 Oct 2017 13:56:26 -0000

Hello dnsop,

draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any
update from 2017-03-09.

Is there a real apetite for work on this document?

We are considering RPZ implementation for Knot Resolver next year but if
the document is not going to move forward I would rather close the
ticket and be done with it. I certainly do commit to implementing
ever-changing protocol without readily available description ...

Is there anyone interested in the document except me and the appointed
editor?

Thank you for replies.
Petr Špaček  @  CZ.NIC


On 18.7.2017 14:13, 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