Re: [dnsext] [Technical Errata Reported] RFC5155 (4622)

Brian Haberman <brian@innovationslab.net> Fri, 19 February 2016 15:11 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1808D1A1B8E for <dnsext@ietfa.amsl.com>; Fri, 19 Feb 2016 07:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOOT9QmyYYUF for <dnsext@ietfa.amsl.com>; Fri, 19 Feb 2016 07:11:32 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9FD1ACDED for <dnsext@ietf.org>; Fri, 19 Feb 2016 07:11:32 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 37335880C7; Fri, 19 Feb 2016 07:11:32 -0800 (PST)
Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 63D1A328081A; Fri, 19 Feb 2016 07:11:31 -0800 (PST)
To: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com
References: <20160218013620.0ABC6180209@rfc-editor.org>
From: Brian Haberman <brian@innovationslab.net>
Message-ID: <56C7309D.8080603@innovationslab.net>
Date: Fri, 19 Feb 2016 10:11:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160218013620.0ABC6180209@rfc-editor.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/k0EQHtIPB9a1yeLByhMR3-Cd-R0>
Cc: dnsext@ietf.org, ogud@ogud.com
Subject: Re: [dnsext] [Technical Errata Reported] RFC5155 (4622)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 19 Feb 2016 15:11:34 -0000

Does anyone have an opinion on the validity of this erratum? It seems
like a reasonable clarification in my reading.

Brian

On 2/17/16 8:36 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5155,
> "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622
> 
> --------------------------------------
> Type: Technical
> Reported by: Robert Edmonds <edmonds@mycre.ws>
> 
> Section: 7.2.8
> 
> Original Text
> -------------
> 7.2.8.  Responding to Queries for NSEC3 Owner Names
> 
>    The owner names of NSEC3 RRs are not represented in the NSEC3 RR
>    chain like other owner names.  As a result, each NSEC3 owner name is
>    covered by another NSEC3 RR, effectively negating the existence of
>    the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
>    can be proven by its RRSIG RRSet.
> 
>    If the following conditions are all true:
> 
>    o  the QNAME equals the owner name of an existing NSEC3 RR, and
> 
>    o  no RR types exist at the QNAME, nor at any descendant of QNAME,
> 
>    then the response MUST be constructed as a Name Error response
>    (Section 7.2.2).  Or, in other words, the authoritative name server
>    will act as if the owner name of the NSEC3 RR did not exist.
> 
> 
> Corrected Text
> --------------
> 7.2.8.  Responding to Queries for NSEC3 Owner Names
> 
>    The owner names of NSEC3 RRs are not represented in the NSEC3 RR
>    chain like other owner names.  As a result, each NSEC3 owner name is
>    covered by another NSEC3 RR, effectively negating the existence of
>    the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
>    can be proven by its RRSIG RRSet.
> 
>    If the following conditions are all true:
> 
>    o  the QNAME equals the owner name of an existing NSEC3 RR, and
> 
>    o  no RR types exist at the QNAME besides NSEC3, nor at any
>       descendant of QNAME,
> 
>    then the response MUST be constructed as a Name Error response
>    (Section 7.2.2).  Or, in other words, the authoritative name server
>    will act as if the owner name of the NSEC3 RR did not exist.
> 
> 
> Notes
> -----
> If the QNAME is equal to the owner name of an existing NSEC3 RR, then the NSEC3 RR type itself will exist at the QNAME, and the second condition will always be false.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5155 (draft-ietf-dnsext-nsec3-13)
> --------------------------------------
> Title               : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
> Publication Date    : March 2008
> Author(s)           : B. Laurie, G. Sisson, R. Arends, D. Blacka
> Category            : PROPOSED STANDARD
> Source              : DNS Extensions
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
>