Re: [dnsext] Clarifying the mandatory algorithm rules

Casey Deccio <casey@deccio.net> Fri, 18 March 2011 16:35 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 27A413A6955 for <dnsext@core3.amsl.com>; Fri, 18 Mar 2011 09:35:26 -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 9PExYQdrjsa0 for <dnsext@core3.amsl.com>; Fri, 18 Mar 2011 09:35:22 -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 6F1663A6954 for <dnsext@ietf.org>; Fri, 18 Mar 2011 09:35:22 -0700 (PDT)
Received: by qyk7 with SMTP id 7so3182538qyk.10 for <dnsext@ietf.org>; Fri, 18 Mar 2011 09:36:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.123.211 with SMTP id q19mr1154534qcr.128.1300466211596; Fri, 18 Mar 2011 09:36:51 -0700 (PDT)
Received: by 10.229.227.203 with HTTP; Fri, 18 Mar 2011 09:36:51 -0700 (PDT)
In-Reply-To: <a06240802c9a7e0807069@10.31.200.117>
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> <AANLkTimUUa5zkr+hZH4jR-euENg_n=9EwtRVBN-cxr9_@mail.gmail.com> <a06240802c9a7b6cb4cc3@192.168.1.105> <AANLkTin+hMZ-27VjkQq7_44zNguMiefhxbgGD+-XZxPP@mail.gmail.com> <a06240802c9a7e0807069@10.31.200.117>
Date: Fri, 18 Mar 2011 09:36:51 -0700
Message-ID: <AANLkTi=4co5mS3RYhK1BvUMOm54wgNAMeKtk3_Zm0ff1@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: dnsext@ietf.org
Content-Type: multipart/alternative; boundary="000e0cd23d1295abff049ec46223"
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, 18 Mar 2011 16:35:26 -0000

On Thu, Mar 17, 2011 at 9:19 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:

> The reason for the specification is to set the expectation of the validator
> (the receiving end).  The specification requires the signer (the sending
> end) to generate and publish at least one signature of each algorithm listed
> in the zone's DS record set.  Because of this rule the validator can expect
> that a signature by a specific algorithm the validator wants to use for a
> set of data in the zone will be available if listed in the DS record set.
>  With this expectation, if the validator receives a data set from the zone
> and cannot obtain a signature, then the validator is to declare a protocol
> failure.


Okay, so the signer sets the expectation of the validator using the
algorithms in the DS RRset.  Now, does this expectation hold for simply
authenticating the DNSKEY RRset or for all zone data?

For example:

- DS RRset has only algorithm 5
- DNSKEY RRset signed by a DNSKEY matching the DS (alg 5)
- DNSKEY RRset contains DNSKEYs with algs 5 and 3
- DNSKEY with alg 3 signs A RRset.

Is there a valid chain to the A RRset, or is it a protocol failure?
Following the principle of "if one chain works, it succeeds", I would say
that it is valid.  But it's unclear whether this is part of the expectation
of the signer for the validator, and even the paragraph quoted above seems
to declare it a protocol failure--although I well understand your position
on principle.  Whether it is valid or not, I believe it should be worded
explicitly to avoid ambiguity and accurately convey principle.

Casey