Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14)

Samuel Weiler <weiler@watson.org> Fri, 13 January 2012 04:20 UTC

Return-Path: <weiler@watson.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83121F8484 for <dnsext@ietfa.amsl.com>; Thu, 12 Jan 2012 20:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP9A2gVYpI2A for <dnsext@ietfa.amsl.com>; Thu, 12 Jan 2012 20:20:15 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9899821F847E for <dnsext@ietf.org>; Thu, 12 Jan 2012 20:20:15 -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 q0D4KFA7074960 for <dnsext@ietf.org>; Thu, 12 Jan 2012 23:20:15 -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 q0D4KFPt074956 for <dnsext@ietf.org>; Thu, 12 Jan 2012 23:20:15 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 12 Jan 2012 23:20:14 -0500
From: Samuel Weiler <weiler@watson.org>
To: dnsext@ietf.org
In-Reply-To: <a06240801cabc9d0de24d@[192.168.129.103]>
Message-ID: <alpine.BSF.2.00.1201122318080.86374@fledge.watson.org>
References: <20111012144101.205a61dff9fc1684c258b274662bb912.3f5e55ecf1.wbe@email00.se cureserver.net> <a06240801cabc9d0de24d@[192.168.129.103]>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-321806595-1326428289=:86374"
Content-ID: <alpine.BSF.2.00.1201122318210.86374@fledge.watson.org>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 12 Jan 2012 23:20:15 -0500 (EST)
Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Jan 2012 04:20:16 -0000

I don't recall seeing much discussion of the below.  As doc editor, I 
would like to hear an extra voice or three chime in before I fix 
this.

As I understand Ed's message, the (signer) name in an RRSIG does need 
to be downcased.  The next name in a NSEC RR does NOT need to be 
downcased.  Is that right?

On Thu, 13 Oct 2011, Edward Lewis wrote:

> In this section of the still-a-draft update to the DNSSEC definition of RFC 4033-4035 an issue has arisen that needs to be addressed.
> 
> # http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14
> #
> #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.
> 
> For the purposes of this email a "major implementation" refers to a widely distributed general purpose implementation of DNS.  It's become apparent
> that two major implementations of validators have differed on downcaseing the RRSIG.
> 
> We've been trying to determine why this problem hasn't surfaced in a real-world outage.  It seems that all major implementations of signers down case
> the RRSIG before signing.
> 
> Treat this as a suggestion.  Unexcuse RRSIG from the list of names that avoid downcasing.  (NSEC is not a problem.)  Any thoughts?
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis             
> NeuStar                    You can leave a voice message at +1-571-434-5468
> 
> Vote for the word of the day:
> "Papa"razzi - father that constantly takes photos of the baby
> Corpureaucracy - The institution of corporate "red tape"
> 
>