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

Barry Raveendran Greene <bgreene@senki.org> Fri, 17 March 2017 13:36 UTC

Return-Path: <bgreene@senki.org>
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 9CE6B129431 for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 06:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level:
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=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 97LPFoTreVLd for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 06:36:11 -0700 (PDT)
Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (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 BE5A5129420 for <dnsop@ietf.org>; Fri, 17 Mar 2017 06:36:10 -0700 (PDT)
Received: from smtp36.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DBE4256EF; Fri, 17 Mar 2017 09:36:09 -0400 (EDT)
X-Auth-ID: bgreene@senki.org
Received: by smtp36.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 4AF3D5442; Fri, 17 Mar 2017 09:36:09 -0400 (EDT)
X-Sender-Id: bgreene@senki.org
Received: from [172.16.1.42] (c-73-92-124-43.hsd1.ca.comcast.net [73.92.124.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 17 Mar 2017 09:36:09 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Barry Raveendran Greene <bgreene@senki.org>
In-Reply-To: <alpine.LRH.2.20.999.1703130533180.18195@bofh.nohats.ca>
Date: Fri, 17 Mar 2017 06:36:07 -0700
Cc: Dave Crocker <dcrocker@bbiw.net>, joel jaeggli <joelja@bogus.com>, tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABC4D46C-08AF-4E79-AEF5-CC091864430D@senki.org>
References: <CADyWQ+ETSd199ok0fgh=PB=--hW7buPgSoCg22aK51Bk4xxBmw@mail.gmail.com> <CADyWQ+GUDg2iA+MQ9xjNLDVvRgnd9PD=pLBNNvp0xK3UZVSqTA@mail.gmail.com> <1AD82FB6-735A-4124-A0A3-2158EC567AD6@nohats.ca> <CAHw9_iK+SWiHZwGgHZRO2T1MLVQZS-2BaeZBzyUuZ0iWHX2ZjA@mail.gmail.com> <fa0b1bd1-f7b8-c3bc-58a3-397c1b118370@bogus.com> <alpine.LRH.2.20.999.1703121922250.11053@bofh.nohats.ca> <19668099-d361-5bd5-7efb-2aab92c190e6@bbiw.net> <alpine.LRH.2.20.999.1703130533180.18195@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MdTclag9p02AFX370TZbw35Jklg>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-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, 17 Mar 2017 13:36:13 -0000

Paul - changes to existing practice is a _new_ document. You take the existing, coded, and deployed specification in as an informational RFC. Then you start a new working group document for the full “IETF version.” 

We’ve done this for many other protocols over the last several decades. Why the push back?


> On Mar 13, 2017, at 4:11 AM, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Sun, 12 Mar 2017, Dave Crocker wrote:
> 
>> On 3/12/2017 4:23 PM, Paul Wouters wrote:
>>> I do not want to adopt it unmodified
>>> as informational RFC for running existing code.
>> 
>> You do not want the IETF to document existing practice?
>> 
>> Really?
> 
> There is a fine line between "bringing existing things to IETF to
> standardize" and "bringing existing things to IETF to document".
> 
> The draft breaks DNSSEC. In its current form it would not have moved
> forward if this work had been done from the start at the IETF. We would
> have asked the authors to come up with a modified solution that does
> not break DNSSEC. So documenting it now after the fact as RFC basically
> bypasses the IETF purposefully.
> 
> I have proposed a method that would not change the RPZ response for a
> non-DNSSEC client, but would add data for DNSSEC capable clients to be
> notified the DNSSEC data was modified (and possibly state why) giving
> DNSSEC capable clients a method to act differently, knowing the data was
> changed for a reason and is not simply a DNS spoofing attack. It can be
> added without breaking existing deployments. If the authors aren't willing
> to do this, why should IETF rubberstamp a DNS protocol that breaks DNSSEC?
> 
> Paul
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop