Re: [dnsext] Section 5.1 of draft-dnssec-bis
Mark Andrews <marka@isc.org> Tue, 08 June 2010 14:36 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1838D28C1C0; Tue, 8 Jun 2010 07:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.249
X-Spam-Level:
X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001]
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 v1KsMzE7+3A2; Tue, 8 Jun 2010 07:36:32 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 839DC28C110; Tue, 8 Jun 2010 07:36:32 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OLzr3-000A3e-UC for namedroppers-data0@psg.com; Tue, 08 Jun 2010 14:32:37 +0000
Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <marka@isc.org>) id 1OLzr0-000A2z-Ud for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 14:32:35 +0000
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D4680EEA91; Tue, 8 Jun 2010 14:32:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o58EWSEB034243; Wed, 9 Jun 2010 00:32:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <201006081432.o58EWSEB034243@drugs.dv.isc.org>
To: Edward Lewis <Ed.Lewis@neustar.biz>
Cc: namedroppers@ops.ietf.org
From: Mark Andrews <marka@isc.org>
References: <a06240800c833dc0dbc79@[192.168.1.104]>
Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis
In-reply-to: Your message of "Tue, 08 Jun 2010 07:48:57 -0400." <a06240800c833dc0dbc79@[192.168.1.104]>
Date: Wed, 09 Jun 2010 00:32:28 +1000
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>
In message <a06240800c833dc0dbc79@[192.168.1.104]>, Edward Lewis writes: > Why does section 5.1 exist? It's going to create problems once > resolvers start validating responses. Because RFC 4034 go the list wrong. RFC 3755, which introduced NSEC had it right. RFC 4034 broke compatibility. Section 5.1 restores compatibility. RFC 3755 The new types will have exactly the same syntax and semantics as specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for the following: 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC RRs MUST NOT be compressed, 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for purposes of DNSSEC canonical form and ordering nor for equality comparison, and 3) An RRSIG with a type-covered field of zero has undefined semantics. The meaning of such a resource record may only be defined by IETF Standards Action. > Section 5.1 says: > > 5. Interoperability Concerns > > 5.1. Errors in Canonical Form Type Code List > > When canonicalizing DNS names, DNS names in the RDATA section of NSEC > and RRSIG resource records are not downcased. > > [RFC4034] Section 6.2 item 3 has a list of resource record types for > which DNS names in the RDATA are downcased for purposes of DNSSEC > canonical form (for both ordering and signing). That list > erroneously contains NSEC and RRSIG. According to [RFC3755], DNS > names in the RDATA of NSEC and RRSIG should not be downcased. > > The same section also erroneously lists HINFO, and twice at that. > Since HINFO records contain no domain names, they are not subject to > downcasing. > > The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC > 3755. This draft now says that the obsoleting document (4034) is to > be updated by the obsoleted document (3755). No. It says that RFC 4034 has a error in it. That the earlier list was correct and that this document is correcting the list to match that in RFC 3755. > The reality-problem here is that RFC 4034's section 6.2 makes sense. > RFC 3755 did not on this matter. When it comes to the DNSSEC types, > DNSSEC can make type-specific rules about the RDATA. Not in the context of why one canonicalize domain names. The only reason to do this is because the name could be compressed. NSEC and RRSIG records have never been allowed to be compressed. > The operations&tools-problem here is that there are tools being > produced that automatically manage the NSEC (and NSEC3) chains. Some > tools are exhibiting unexpected behavior in operations because they > follow the un-vetted draft and not the existing proposed standard. No. There is a problem because we missed the fact that the list was wrong and in the process broke compatibility with existing code for no good reason. The draft is there to catch the errata in the DNSSEC documents and that includes RFC 4034. Perhaps it is time to publish the draft. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Discussing IPv4 address policy is like deciding what to eat on the Titanic. > --============_-936124530==_ma============ > Content-Type: text/html; charset="us-ascii" > > <!doctype html public "-//W3C//DTD W3 HTML//EN"> > <html><head><style type="text/css"><!-- > blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } > --></style><title>Section 5.1 of > draft-dnssec-bis</title></head><body> > <div>Why does section 5.1 exist? It's going to create problems > once resolvers start validating responses.</div> > <div><br></div> > <div>Section 5.1 says:</div> > <div><br></div> > <div>5. Interoperability Concerns<br> > <br> > 5.1. Errors in Canonical Form Type Code List<br> > <br> > When canonicalizing DNS names, DNS names in the RDATA > section of NSEC<br> > and RRSIG resource records are not downcased.<br> > <br> > [RFC4034] Section 6.2 item 3 has a list of resource > record types for<br> > which DNS names in the RDATA are downcased for purposes > of DNSSEC<br> > canonical form (for both ordering and signing). > That list<br> > erroneously contains NSEC and RRSIG. According to > [RFC3755], DNS<br> > names in the RDATA of NSEC and RRSIG should not be > downcased.<br> > <br> > The same section also erroneously lists HINFO, and twice > at that.<br> > Since HINFO records contain no domain names, they are not > subject to</div> > <div> downcasing.</div> > <div><br></div> > <div>The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC > 3755. This draft now says that the obsoleting document (4034) is > to be updated by the obsoleted document (3755).</div> > <div><br></div> > <div>The reality-problem here is that RFC 4034's section 6.2 makes > sense. RFC 3755 did not on this matter. When it comes to > the DNSSEC types, DNSSEC can make type-specific rules about the > RDATA.</div> > <div><br></div> > <div>The operations&tools-problem here is that there are tools > being produced that automatically manage the NSEC (and NSEC3) chains. > Some tools are exhibiting unexpected behavior in operations because > they follow the un-vetted draft and not the existing proposed > standard.</div> > <div><br></div> > <x-sigsep><pre>-- > </pre></x-sigsep> > <div > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span > ></span>-=-=-=-</div> > <div>Edward > Lewis <span > ></span> <br> > NeuStar <span > ></span> You can > leave a voice message at +1-571-434-5468</div> > <div><br></div> > <div>Discussing IPv4 address policy is like deciding what to eat on > the Titanic.</div> > </body> > </html> > --============_-936124530==_ma============-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [dnsext] Section 5.1 of draft-dnssec-bis Edward Lewis
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Mark Andrews
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Edward Lewis
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Edward Lewis
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Mark Andrews
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Mark Andrews
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Edward Lewis
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Mark Andrews
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Edward Lewis
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Donald Eastlake
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Edward Lewis
- Re: [dnsext] Section 5.1 of draft-dnssec-bis Donald Eastlake