Re: [dnsext] Clarifying the mandatory algorithm rules
Edward Lewis <Ed.Lewis@neustar.biz> Thu, 17 March 2011 13:22 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 93E353A68AD for <dnsext@core3.amsl.com>; Thu, 17 Mar 2011 06:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level:
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ofndT-TcSDeu for <dnsext@core3.amsl.com>; Thu, 17 Mar 2011 06:22:10 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 544BE3A695E for <dnsext@ietf.org>; Thu, 17 Mar 2011 06:22:09 -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 p2HDNRKY051678; Thu, 17 Mar 2011 09:23:28 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.117] by Work-Laptop-2.local (PGP Universal service); Thu, 17 Mar 2011 09:23:35 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 17 Mar 2011 09:23:35 -0400
Mime-Version: 1.0
Message-Id: <a06240802c9a7b6cb4cc3@[192.168.1.105]>
In-Reply-To: <AANLkTimUUa5zkr+hZH4jR-euENg_n=9EwtRVBN-cxr9_@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>
Date: Thu, 17 Mar 2011 09:19:42 -0400
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: multipart/alternative; boundary="============_-911754286==_ma============"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: ed.lewis@neustar.biz
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: Thu, 17 Mar 2011 13:22:12 -0000
>"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." No, no, no, quite the opposite. For any given resource record set, a validator ought to try algorithms until any one works. Same for signatures and keys. I can't think of any situation in which DNS should do "everything". It is a "do something" protocol, not a "do everything" protocol. The goal is "get the answer to the client" not "ensure security is followed." Maybe the situation is unclear. First, when obtaining an answer, DNS is mostly done as it was without DNSSEC, i.e., depth-first to the answer. The "mostly" means that in addition to this depth-first plunge, DNSSEC records are also held. If the answer has a signature and the answer is below a trust anchor, then walk backwards from the answer to the trust anchor. That means starting with the answer's RRSIG's signer identifier. Then validate the signer identifier and so on. If there is ever a choice, again, default to a depth-first strategy to find the first chain that can be built. If no chain can be built, the reason will determine if the situation is a service failure or an explicitly broken chain. If the answer has no signature, then you need to first determine if there is a need to find one. Starting with the appropriate trust anchor, go depth first towards the answer. The dive is from zone to zone, looking for an unbroken chain. If a delegation as no DS record set, then DNSSEC "stops." If a delegation has a DS record set but no algorithm is understood by the validator, then DNSSEC "stops." If the delegation has a DS record set with one algorithm that is understood, the next zone is signed in just that algorithm and is why each set has to have each algorithm. If the delegation has a DS record set has a number of useable algorithms...just pick one, try it, if not, try another, and so on. DNS/SEC has to have a depth-first, goal-oriented search. It is not a navel-gazing, breadth-first search. There's nothing wrong in pre-fetching, fleshing out the tree's trustworthiness, and other activity, but that shouldn't be critical path when answering a question. At 11:18 -0700 3/16/11, Casey Deccio wrote: On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis <<mailto:Ed.Lewis@neustar.biz>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 _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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!"
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- [dnsext] Clarifying the mandatory algorithm rules Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Phillip Hallam-Baker
- Re: [dnsext] Clarifying the mandatory algorithm r… Florian Weimer
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… George Barwood
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Doug Barton
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Paul Vixie
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Phillip Hallam-Baker
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Olafur Gudmundsson
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Alfred Hönes
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- [dnsext] MAR proposal #1: Algorithm downgrade pro… Samuel Weiler
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Samuel Weiler
- [dnsext] MAR proposal #2: Allowing pre-publishing… Samuel Weiler
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Edward Lewis
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Edward Lewis
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Mark Andrews
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Paul Hoffman
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Paul Hoffman
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Brian Dickson
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Marc Lampo
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Matthijs Mekking
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Joe Abley
- Re: [dnsext] Clarifying the mandatory algorithm r… weiler