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

Suzanne Woolf <suzworldwide@gmail.com> Tue, 18 July 2017 12:14 UTC

Return-Path: <suzworldwide@gmail.com>
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 8BE69131DF4 for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 05:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 S3QNYIjVwRgi for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 05:14:08 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2978C131B31 for <dnsop@ietf.org>; Tue, 18 Jul 2017 05:13:58 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id a10so26843668wrd.0 for <dnsop@ietf.org>; Tue, 18 Jul 2017 05:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=88wm0EyWOlaSpW7xAy+foDS6Asxq3lrkbXab34ZhgIE=; b=cYs2iOqKsiHNKqR1eXUau6qYrr3sTSQXZpBwRNirLP8tfIfSYbx7xfPA4Wm/NfKIsV wh0PfSFgb8whuWksIR53iB3ixsHpMq2XCAD8hM7A448gbx7nJg8EwTJ+6HeRnyUTzr2h 82MqGfCtCmVKuooeAnp+XTg0VV/Q58TCuJqwmkGj7SdvSBqRSs+XFxy4qV4QHRMEbWEi Ln86Ayyz7LxQtqWdgrOh8O2yf15JmlhBC79HBvnTxH5ZYP4v53fdZqUXFLVv0nOhvk78 nl2xchyS660VvQqrCzpKNvcoiBkwjUn1JiQO7cxhPbHCQ2nTXQj06c8TDLu6le4yF7/D DNYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=88wm0EyWOlaSpW7xAy+foDS6Asxq3lrkbXab34ZhgIE=; b=Bh/uoMAp3dmraEyN3WwFuAkXe7h9BotYHQx5x0Fv6A9SQ6dRE6z3ctA2IYoHyP2N16 gPw5MCzqsXd3jK7JCg7gZmooERoVw4Ui2KI+LX/WZKNhRKCaytS16LXo6wWom5Csa8Hu 15Y6ZwjxG2SoITqM0ZAXCdxo3j8F4UL8VA9gJUBSx1N9w09T+c3fGnjnJ4ho8RM15Phg jxKcxamjiLdYWZ8Ej73wNx3LOadl8iVHGX3D7/PZD54u/asAtXpxG1Xf+ZyB0MVwJtKA SgTecKTS79F32wAxgdzrLrhnfuo8kVUw64AzkmosQ2eQRvhdSd78fypKQDBdQkPDoHur hq7A==
X-Gm-Message-State: AIVw111TObeIOGZgoeZBmswCzp96/RERKdIFuOj6GGMnJuGURgQ3EKUB D92z1EUFS27oueGcUl4=
X-Received: by 10.28.136.147 with SMTP id k141mr2011296wmd.14.1500380036321; Tue, 18 Jul 2017 05:13:56 -0700 (PDT)
Received: from dhcp-8904.meeting.ietf.org (dhcp-8904.meeting.ietf.org. [31.133.137.4]) by smtp.gmail.com with ESMTPSA id p13sm3739854wma.8.2017.07.18.05.13.55 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 05:13:55 -0700 (PDT)
To: dnsop@ietf.org
From: Suzanne Woolf <suzworldwide@gmail.com>
Message-ID: <d7dd539d-e2b9-b708-cc7e-8b417ff06a20@gmail.com>
Date: Tue, 18 Jul 2017 08:13:54 -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
Content-Type: multipart/alternative; boundary="------------F195C6DEAA8682EA3DCC406D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0VTIIFhuIybW2J5_mITgnpjp20g>
Subject: [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: Tue, 18 Jul 2017 12:14:10 -0000

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