Re: [dnsext] Clarifying the mandatory algorithm rules
Edward Lewis <Ed.Lewis@neustar.biz> Fri, 11 March 2011 13:40 UTC
Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B27E3A6BFF for <dnsext@core3.amsl.com>; Fri, 11 Mar 2011 05:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level:
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv8mKoO6Pn0s for <dnsext@core3.amsl.com>; Fri, 11 Mar 2011 05:40:29 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6D6263A69AE for <dnsext@ietf.org>; Fri, 11 Mar 2011 05:40:29 -0800 (PST)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2BDfcfI065151; Fri, 11 Mar 2011 08:41:39 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Fri, 11 Mar 2011 08:41:47 -0500
X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 11 Mar 2011 08:41:47 -0500
Mime-Version: 1.0
Message-Id: <a06240800c99fd2d69d4a@[10.31.200.120]>
In-Reply-To: <4D79DDFA.3010006@nlnetlabs.nl>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE51293.5040605@nlnetlabs.nl> <a06240801c9101620d463@[192.168.128.163]> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl><alpine.BSF.2.00.1103100812260.60284@fledge .watson.org> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl>
Date: Fri, 11 Mar 2011 08:34:57 -0500
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: edward.lewis@neustar.biz
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2011 13:40:31 -0000
"Could" as in, SHOULD NOT if I had to choose from the 2119 menu of options. I'd prefer "not recommended" but that isn't on the menu. I would prefer to use this bon mot: "I encourage my competitors to behave this way." ...to be clear, I am talking about the validator actually checking the signatures. Having the ability to, sure, that is important. But "if one chain works, it succeeds" is an important spirit. At 9:31 +0100 3/11/11, Matthijs Mekking wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >On November 30, Wouter acknowledges that changes need to be made to the >Unbound implementation and asks for guidance: > > http://www.ietf.org/mail-archive/web/dnsext/current/msg10115.html > >Presenting two options: >* One signature is enough (the lenient way) >* Check the algorithms. > >But when checking the algorithms, thou should not use the DNSKEY RRset, >but the DS RRset. > >I think the general consensus is that a validator should at least be >able to check the algorithms in the DS RRset (Please correct me if I am >being to hasty in my conclusion). There is still debate whether the >validator SHOULD or MAY do this (Ed Lewis argued the term 'could', I >think that translates to the RFC2119 term MAY). > > Proposed text would then be: > > "The validator SHOULD or MAY check (choice here) that the algorithms > signaled in the DS-set work (but only for algorithms supported by > the validator, of course)." > >Best regards, > >Matthijs > > > > >On 03/10/2011 11:34 PM, Mark Andrews wrote: >> >> In message >><alpine.BSF.2.00.1103100812260.60284@fledge.watson.org>, Samuel Weil >> er writes: >>> On Tue, 30 Nov 2010, W.C.A. Wijngaards wrote: >>> >>>> It is clear that checking the set of algorithms present in the DNSKEY >>>> set is not a good idea, and checking the set of algorithms from the DS >>>> set is the right, more lenient way to go. >>> >>> I apologize for checking out of this discussion last fall. >>> >>> I would like the WG's help understanding where you want to go with >>> this topic. I don't fully understand the argument in favor of not >>> checking the algorithms on the child side of the zone cut (= the ones >>> in the DNSKEY RRset), nor am I sure that was the direction everyone >>> seemed to want to go. Could someone summarize the current state of >>> this? >>> >>> My own inclination is (still) to treat this as a clarification, saying >>> that validators are not required to enforce these rules. (In other >>> words, the extra checks Unbound did were just fine, though >>> unnecessary. BIND's lenient approach was also fine.) Two specific >>> pieces of proposed text can be found in the first message in this >>> thread, dated 18 November 2010. >> >> While we think about this ISC has also had bug reports claiming >> that is we don't publish DNSKEY prior to signing with them we are >> break RFC 4035 because it allows verification of every RRSIG as a >> policy and the only way to do that is to publish the DNSKEY prior >> to use. >> >> If other RRSIG RRs also cover this RRset, the local resolver security >> policy determines whether the resolver also has to test these RRSIG >> RRs and how to resolve conflicts if these RRSIG RRs lead to differing >> results. >> >>> -- Sam >>> _______________________________________________ >>> dnsext mailing list >>> dnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsext >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.10 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iQEcBAEBAgAGBQJNed35AAoJEA8yVCPsQCW52EcIALwitOh1IOVX6AqV28GNEYYM >VSSlPZyVWYxD0LCVTWq5aleh3EAJ3T4BdRio795mlNrc/vLi0VNL8FqRI8U7mYk8 >I+acLNJGhoFpEFeVF+rOXpoZ3yfTerUctv1mmeyeO/2iW+PF++BJh67bcUV34h1p >UvP3lMZCBqIpbR3uhRITjF5JsZ2yaqwoARMyIw58MM72M2Y0X3IuJCYSKSl3ANzJ >nwBdrtZZcRmfmzJAY8PvDO0/mcyws1iK4JtiMMyXPNAfgxyBEeyxIe8YUR1yrQgL >tcxHaDyTsaPp1GnqAbqucYWdhr17QZ1b6SUmh9qyYW1leKXZSecFUp0tjdhCYQo= >=qOVC >-----END PGP SIGNATURE----- >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!"
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- [dnsext] Clarifying the mandatory algorithm rules Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Phillip Hallam-Baker
- Re: [dnsext] Clarifying the mandatory algorithm r… Florian Weimer
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… George Barwood
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Doug Barton
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Paul Vixie
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Phillip Hallam-Baker
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Olafur Gudmundsson
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Alfred Hönes
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- [dnsext] MAR proposal #1: Algorithm downgrade pro… Samuel Weiler
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Samuel Weiler
- [dnsext] MAR proposal #2: Allowing pre-publishing… Samuel Weiler
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Edward Lewis
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Edward Lewis
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Mark Andrews
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Paul Hoffman
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Paul Hoffman
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Brian Dickson
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Marc Lampo
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Matthijs Mekking
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Joe Abley
- Re: [dnsext] Clarifying the mandatory algorithm r… weiler