Re: [dnsext] Clarifying the mandatory algorithm rules

Matthijs Mekking <matthijs@NLnetLabs.nl> Fri, 11 March 2011 08:31 UTC

Return-Path: <matthijs@nlnetlabs.nl>
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 7A0BC3A6BF0 for <dnsext@core3.amsl.com>; Fri, 11 Mar 2011 00:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level:
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4NRsjaphoK7z for <dnsext@core3.amsl.com>; Fri, 11 Mar 2011 00:30:41 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 1B1E53A6BF7 for <dnsext@ietf.org>; Fri, 11 Mar 2011 00:30:40 -0800 (PST)
Received: from [192.168.1.10] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p2B8Vsij055702 for <dnsext@ietf.org>; Fri, 11 Mar 2011 09:31:54 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl)
Message-ID: <4D79DDFA.3010006@nlnetlabs.nl>
Date: Fri, 11 Mar 2011 09:31:54 +0100
From: Matthijs Mekking <matthijs@NLnetLabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: dnsext@ietf.org
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>
In-Reply-To: <20110310223438.978E9C0E902@drugs.dv.isc.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [213.154.224.1]); Fri, 11 Mar 2011 09:31:55 +0100 (CET)
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 08:31:00 -0000

-----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>rg>, 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-----