Re: [dnsext] Clarifying the mandatory algorithm rules

Casey Deccio <casey@deccio.net> Wed, 16 March 2011 18:17 UTC

Return-Path: <casey@deccio.net>
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 CF4E13A6A33 for <dnsext@core3.amsl.com>; Wed, 16 Mar 2011 11:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 B+vLJpAsAJX5 for <dnsext@core3.amsl.com>; Wed, 16 Mar 2011 11:17:01 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id C88023A6A27 for <dnsext@ietf.org>; Wed, 16 Mar 2011 11:17:00 -0700 (PDT)
Received: by qyk7 with SMTP id 7so1649993qyk.10 for <dnsext@ietf.org>; Wed, 16 Mar 2011 11:18:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.18.9 with SMTP id u9mr347716qaa.126.1300299506839; Wed, 16 Mar 2011 11:18:26 -0700 (PDT)
Received: by 10.229.227.203 with HTTP; Wed, 16 Mar 2011 11:18:26 -0700 (PDT)
In-Reply-To: <a06240800c9a50cf4632a@10.31.200.110>
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> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> <alpine.BSF.2.00.1103141750530.74870@fledge.watson.org> <a06240800c9a50cf4632a@10.31.200.110>
Date: Wed, 16 Mar 2011 11:18:26 -0700
Message-ID: <AANLkTimUUa5zkr+hZH4jR-euENg_n=9EwtRVBN-cxr9_@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: dnsext@ietf.org
Content-Type: multipart/alternative; boundary="bcaec51a870e34f06a049e9d9266"
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: Wed, 16 Mar 2011 18:17:01 -0000

On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:

> The specification requires the generation of a signature of each algorithm
> in the DS record to set the expectation of the validator (remote end).  The
> expectation is that if the DS record set indicates that algorithm X is in
> use, there will be a signature of algorithm X to be had.  If this
> expectation is not met, then the validator is to declare a protocol failure.
>
>
For further clarification...  It seems like you are favorable towards the
validator verifying an RRSIG for every algorithm (which it understands, of
course) that exists in the DS RRset.  Is this verification just for the
RRSIGs made by SEP (i.e., corresponding to DS RRs) DNSKEYs covering the
DNSKEY RRset, or for any arbitrary RRSIG in the zone?  If the former, once
you have authenticated the DNSKEY RRset (with all the algorithms in the DS),
then an RRSIG may be verified by any DNSKEY in the DNSKEY RRset, regardless
of algorithm; if the latter, then the algorithms must play a part in
validating any RRset in the zone.  The former seems more reasonable to me.
It seems like perhaps your view has changed from SHOULD NOT to SHOULD in one
of these regards?

In either case, I think that a bit more wording should be added to the
proposed text to make it clear what is expected of the the validator, in
terms of which RRSIG to check algorithms for, depending on what consensus
is.

Casey