Re: [dnsext] Clarifying the mandatory algorithm rules

Samuel Weiler <weiler@watson.org> Mon, 14 March 2011 13:09 UTC

Return-Path: <weiler@watson.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 94A043A6D35 for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 06:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.724
X-Spam-Level:
X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 d+PdgyQyMg19 for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 06:09:04 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C4FA23A6D18 for <dnsext@ietf.org>; Mon, 14 Mar 2011 06:09:04 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2EDAROm045067; Mon, 14 Mar 2011 09:10:27 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2EDARnP045064; Mon, 14 Mar 2011 09:10:27 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Mon, 14 Mar 2011 09:10:27 -0400
From: Samuel Weiler <weiler@watson.org>
To: Matthijs Mekking <matthijs@NLnetLabs.nl>
In-Reply-To: <4D79DDFA.3010006@nlnetlabs.nl>
Message-ID: <alpine.BSF.2.00.1103140901170.99213@fledge.watson.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>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 14 Mar 2011 09:10:27 -0400 (EDT)
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: Mon, 14 Mar 2011 13:09:05 -0000

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.

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