Re: [dnsext] Clarifying the mandatory algorithm rules

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 18 March 2011 16:58 UTC

Return-Path: <Ed.Lewis@neustar.biz>
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 445C83A6995 for <dnsext@core3.amsl.com>; Fri, 18 Mar 2011 09:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 LMgGJsk+5v7e for <dnsext@core3.amsl.com>; Fri, 18 Mar 2011 09:58:02 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 472213A696F for <dnsext@ietf.org>; Fri, 18 Mar 2011 09:58:02 -0700 (PDT)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2IGxLnW062400; Fri, 18 Mar 2011 12:59:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Fri, 18 Mar 2011 12:59:26 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 18 Mar 2011 12:59:26 -0400
Mime-Version: 1.0
Message-Id: <a06240802c9a93d762e13@[10.31.200.112]>
In-Reply-To: <AANLkTi=4co5mS3RYhK1BvUMOm54wgNAMeKtk3_Zm0ff1@mail.gmail.com>
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> <AANLkTi=4co5mS3RYhK1BvUMOm54wgNAMeKtk3_Zm0ff1@mail.gmail.com>
Date: Fri, 18 Mar 2011 12:59:17 -0400
To: Casey Deccio <casey@deccio.net>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
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: Fri, 18 Mar 2011 16:58:03 -0000

At 9:36 -0700 3/18/11, Casey Deccio wrote:


>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?

No, the specification sets expectations.  I don't mean to be a pain, 
but the first words say this: "The reason for the specification is to 
set the expectation."  I mean that in the strictest sense.  The 
validator knows there's supposed to be X because the spec says so.

>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?

Depends.  If the validator knows both 3 and 5, then it can build a 
chain and it's cool.  If the validator only knows 5, then there's a 
missing piece.  If the validator only knows 3, there's no chain to 
the data.

In summary:
Validator knows 3 & 5 - validates
Validator knows only 3 - data is accepted as not-signed.
Validator knows only 5 - service failure as *expected* signature is not found*
Validator doesn't to 3 & 5 - accepted as not-signed
Validator doesn't do DNSSEC - accepted as not-signed

*not found = not obtainable, can't get it, ...

>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.

It is always up to the validator to decide if it accepts the data. 
Local policy and DNSSEC is about protecting the cache.  DNSSEC is NOT 
designed to enforce proper operations, it is NOT to force the zone 
admin into doing anything.  Remember, DNSSEC is optional to the 
protocol, it's the validators that want to pull the data for 
protection.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"