[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