[dnsext] Clarifying the mandatory algorithm rules
Samuel Weiler <weiler@watson.org> Thu, 18 November 2010 11:01 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 1EF7B3A681F for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 03:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 8NfbefKVnj6t for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 03:01:19 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0BA7F3A681D for <dnsext@ietf.org>; Thu, 18 Nov 2010 03:01:18 -0800 (PST)
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 oAIB25eb087978 for <dnsext@ietf.org>; Thu, 18 Nov 2010 06:02:05 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oAIB25A8087975 for <dnsext@ietf.org>; Thu, 18 Nov 2010 06:02:05 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 18 Nov 2010 06:02:05 -0500
From: Samuel Weiler <weiler@watson.org>
To: dnsext@ietf.org
Message-ID: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 18 Nov 2010 06:02:06 -0500 (EST)
Subject: [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, 18 Nov 2010 11:01:20 -0000
Recently CZNIC reported on some algorithm rollover problems they encountered when they didn't follow the "mandatory algorithm rules" in the "Zone Signing" section of RFC4035. These rules create a method to signal to resolvers what algorithms are in use in a zone. As historical perspective, these rules were written in order to avoid the dilemma of opening resolvers to a downgrade attack or discouraging the use of new algorithms. CZNIC published a DNSKEY for a "new" algorithm without simultaneously publishing the corresponding RRSIGs. Unbound started rejecting answers from .cz because the zone didn't also include the new RRSIGs, even though Unbound fully supported the old algorithm and the RRSIGs for that old algorithm were present in the zone. These rules are indeed for zone operators and/or signers and do not need to be enforced by a validator. While I haven't worked through the validation sections of 4035 closely, I think Unbound is violating the RFC by checking for this. (It would fine for Unbound to disable support for the "old" algorithm entirely, in which case the answers should indeed be rejected, but that isn't what happened here.) In contrast, BIND found the signatures from the "old" algorithm sufficient. I've heard folks from CZNIC advocating adding some clarifications to 4641bis and other operational documents reminding zone operators of these rules, perhaps in better language. I generally support that. I've also been encouraged to add an explanation of this to dnssec-bis-updates. Since validator implementers did different things, I agree that clarification is in order. The most general thing we could say is "Pay attention to the section headings in RFC4035. Note that Section 2 ("Zone Signing") provides guidance to zone signers, not resolvers. Resolvers should pay careful attention to Sections 4 and 5 ("Resolving" and "Authenticating DNS Responses") and do not need to separately check for compliance with every item in Section 2. In particular the "mandatory algorithm rules" in the last paragraph of section 2.2 do not need to be enforced by a resolver. Note that this document makes some minor changes to the validation rules in RFC4035, including the rules for handling DS records with unknown message digest algorithms." I'm not sure if the generalization (that validators can ignore section 2) is 100% correct. Is it? Alternatively, we could say something specific: "The last paragraph of RFC4035 Section 2.2 includes rules for which algorithms must be used to sign a zone. Since these rules have been confusing, we restate them in different language here: Every algorithm present in a zone's DS RRset (if any) must also be present in its DNSKEY RRset. Every algorithm present in the DNSKEY RRset must be used to sign every RRset in the zone, including the DNSKEY RRset itself. If more than one key of the same algorithm is in the DNSKEY RRset, it is sufficient to sign each RRset with any subset of these DNSKEYs. It is acceptable to sign some RRsets with one subset of keys (or key) and other RRsets with a different subset, so long as at least one DNSKEY of each ALGORITHM is used to sign each RRset. Likewise, if there are DS records for multiple keys of the same algorithm, any subset of those may appear in the DNSKEY RRset. Furthermore, note that these rules are for zone operators and zone operators, as might be inferred from the Section 2 heading: "Zone Signing". These rules do not need to be separately enforced by validating resolvers." Does the WG have a preference for which version of this to add to dnssec-bis-updates? By default, I propose to add the specific one. If someone else has walked through RFC4035 Sections 4 and 5 carefully, perhaps we could use the general one. I also welcome other restatements of the rules: I wrote the original ones which have been confusing, and having someone else rewrite them might make more sense. -- Sam Weiler
- 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