Re: [dnsext] Clarifying the mandatory algorithm rules

Mark Andrews <marka@isc.org> Thu, 10 March 2011 22:33 UTC

Return-Path: <marka@isc.org>
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 E8C2B3A6ADE for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 14:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level:
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599]
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 60yH5pBtqLXe for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 14:33:34 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id D1CA73A6866 for <dnsext@ietf.org>; Thu, 10 Mar 2011 14:33:33 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 581F6C9423; Thu, 10 Mar 2011 22:34:41 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E77C2216C1E; Thu, 10 Mar 2011 22:34:40 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 978E9C0E902; Fri, 11 Mar 2011 09:34:38 +1100 (EST)
To: Samuel Weiler <weiler@watson.org>
From: Mark Andrews <marka@isc.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>
In-reply-to: Your message of "Thu, 10 Mar 2011 14:18:30 CDT." <alpine.BSF.2.00.1103100812260.60284@fledge.watson.org>
Date: Fri, 11 Mar 2011 09:34:38 +1100
Message-Id: <20110310223438.978E9C0E902@drugs.dv.isc.org>
Cc: dnsext@ietf.org
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: Thu, 10 Mar 2011 22:33:35 -0000

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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org