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

Vernon Schryver <vjs@rhyolite.com> Sun, 01 January 2017 22:43 UTC

Return-Path: <vjs@rhyolite.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 CD135129408 for <dnsop@ietfa.amsl.com>; Sun, 1 Jan 2017 14:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 czPuSKlKNj3q for <dnsop@ietfa.amsl.com>; Sun, 1 Jan 2017 14:43:24 -0800 (PST)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 00B571270B4 for <dnsop@ietf.org>; Sun, 1 Jan 2017 14:43:23 -0800 (PST)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v01Mh9de005063 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Sun, 1 Jan 2017 22:43:09 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v01Mh84e005062 for dnsop@ietf.org; Sun, 1 Jan 2017 22:43:08 GMT
Date: Sun, 01 Jan 2017 22:43:08 +0000
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201701012243.v01Mh84e005062@calcite.rhyolite.com>
To: dnsop@ietf.org
In-Reply-To: <alpine.LRH.2.20.1701011313510.23906@bofh.nohats.ca>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e2HAjRA5Fsn3c-ARRMy1xG8Jn64>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 01 Jan 2017 22:43:36 -0000

> From: Paul Wouters <paul@nohats.ca>

> Some of us tried that and were told "that's not how RPZ works, we are
> not changing how RPZ works".

As I've repeatedly written, the purpose of the current draft is to
describe the current RPZ protocol.  The current draft and the protocol
it describes are not intended to and cannot prevent the specification
of other protocols, include protocols that might be called "RPZ."


> The only thing I asked for is tracability and accountability

As much tracability and accountability as can be hoped for is already
present with the RPZ SOA in the additional section.

>                                                               but not
> witholding DNSSEC information but by passing it along in a different
> section so that:
>
> - RPZ still works as it does now for existing users/providers
>
> - In the future RPZ filtering cannot be used as an out-of-the-box
>    involuntary censorship tool.
>
> - Accountability can be added by adding a different key of last
>    mile trust anchor.
>
> I'm interested in hearing technical reasons why this change cannot be
> done, ...

Paul Wouters has not made his idea clear to me (but let's keep talk
about it public at least as far as I'm concerned).  My best guesses about
it conclude that putting RRs that as far as DNS clients could tell
are irrelevant to the answer section into the authority section would
make some clients unhappy.  (Since it's not my idea, never mind that
I suspect that fewer DNS clients might break if apparently irrelevant
RRs were added to the additional section instead of the authority
section.)

On the other hand, Paul Woulters' ostensible goal is presumably that
the organizations responsible for any rewriting to be identifiable
during the investigations of problems and then held accountable.  They
are
  - men hidden in the middle using mechanisms other than RPZ, but it
     would be silly to expect them to step forward to be traced or held
     accountable.
  - the people running the recursive resolver with RPZ that sent
     the rewritten response, but the IP address of the recursive
     resolver already identifies them
  - the people that provided the policy zone containg the rule that
     used to modify the response, but the SOA already in the additional
     section points to them and also identifies the version of the rule.

But these guesses of mine about the idea are irrelevant.  Someone
should write a technical proposal for the idea and submit it as an I-D
or here as words that could be added to the current RPZ draft.  That
someone is not me; I told Paul Wouters in response to his private mail
on Dec 22:

] Please write whatever Internet Drafts that are needed, but please
] understand that I have no current interest in a new kind of RPZ.
] ...
] No, your proposals for new rtypes and shifting A and AAAA RRsets from
] the answer section to authority section might be good and reasonable
] in another context, but they are irrelevant to a description of RPZ
] as it currently exists.


Vernon Schryver    vjs@rhyolite.com