Re: [dnsext] Clarifying the mandatory algorithm rules

Mark Andrews <marka@isc.org> Mon, 14 March 2011 21:32 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 241DC3A6F40 for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 14:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vrBeGsgP343N for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 14:32:27 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1F8233A6BB9 for <dnsext@ietf.org>; Mon, 14 Mar 2011 14:32:17 -0700 (PDT)
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.ams1.isc.org (Postfix) with ESMTPS id F2EB75F9863; Mon, 14 Mar 2011 21:33:24 +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 ADEA5216C22; Mon, 14 Mar 2011 21:33:22 +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 A2799C8CA0B; Tue, 15 Mar 2011 08:33:19 +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> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org>
In-reply-to: Your message of "Mon, 14 Mar 2011 09:10:27 EDT." <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org>
Date: Tue, 15 Mar 2011 08:33:19 +1100
Message-Id: <20110314213319.A2799C8CA0B@drugs.dv.isc.org>
Cc: dnsext@ietf.org, Matthijs Mekking <matthijs@NLnetLabs.nl>
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: Mon, 14 Mar 2011 21:32:28 -0000

In message <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org>, Samuel Wei
ler writes:
> Thank you very much!
> 
> > 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)."
> 
> I understand the desire for MAY check all algorithms, and I'm fine 
> with that.  (I tend to agree with Ed on SHOULD NOT, but 
> whatever.)
> 
> I do not yet understand the reason for looking only at the DS RRset 
> and not also the DNSKEY RRset, and I'd very much like to.

The rule was put in there to ensure that a signer generated a zone
which had the information required for the validator to validate
the records in the zone.

> If we tell validators to that the DNSKEY RRset isn't being used for 
> signalling, then presumably we're also changing what it means to be a 
> "properly signed zone".  What's the new definition?  And why that 
> change?
> 
> -- 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