Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <> Fri, 11 March 2011 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B27E3A6BFF for <>; Fri, 11 Mar 2011 05:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.576
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bv8mKoO6Pn0s for <>; Fri, 11 Mar 2011 05:40:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6D6263A69AE for <>; Fri, 11 Mar 2011 05:40:29 -0800 (PST)
Received: from Work-Laptop-2.local ( []) by (8.14.4/8.14.4) with ESMTP id p2BDfcfI065151; Fri, 11 Mar 2011 08:41:39 -0500 (EST) (envelope-from
Received: from [] 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@[]>
In-Reply-To: <>
References: <> <> <a06240801c9101620d463@[]> <> <><alpine.BSF.2.00.1103100812260.60284@fledge> <> <>
Date: Fri, 11 Mar 2011 08:34:57 -0500
To: <>
From: Edward Lewis <>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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." 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:
>Hash: SHA1
>On November 30, Wouter acknowledges that changes need to be made to the
>Unbound implementation and asks for guidance:
>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,
>On 03/10/2011 11:34 PM, Mark Andrews wrote:
>>  In message 
>><>>, 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
>Version: GnuPG v1.4.10 (GNU/Linux)
>Comment: Using GnuPG with Mozilla -
>dnsext mailing list

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!"