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

"Blacka, David" <davidb@verisign.com> Fri, 19 February 2016 16:37 UTC

Return-Path: <davidb@verisign.com>
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 59F381B3211 for <dnsext@ietfa.amsl.com>; Fri, 19 Feb 2016 08:37:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 HN8tIuNJ4NU0 for <dnsext@ietfa.amsl.com>; Fri, 19 Feb 2016 08:37:51 -0800 (PST)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86721B31F5 for <dnsext@ietf.org>; Fri, 19 Feb 2016 08:37:51 -0800 (PST)
Received: by mail-qg0-x261.google.com with SMTP id b35so8736551qge.0 for <dnsext@ietf.org>; Fri, 19 Feb 2016 08:37:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=zjScveNGCvi5o9xc5els8+6r0zO6JgoCOUw5Xj5gNM8=; b=qlADa+VP5IMlntFm3KcH3ozcVf+PunMw1mwbqg+U6XRB4VajWeW6FPAq9zvun0sn/t G6HnmiL9ouiDecbPntqG5a62GLQArGKG0S69IMUNz2UcWIKT3WMcsuTi4rBuYf3p4AzD Ctd8t6cbLoPb8z0ZBW+jrUCmHman/Yvp0764MOHVMLY91qtC+9/5C5jSMq3GnjOWh4SY eu+FMOJhL/tKtp5IoTQqbNAIuev69FuJ2xJbuN/8p1f4wdhYmj2wUioccapMifcHV6kf Bjuu6/KHYWlRNKsRncudiWE3xlYrgF9cJpJ/p7XLxQFlbtT+xt/hMfLdgV85dZexZGlj ZcuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=zjScveNGCvi5o9xc5els8+6r0zO6JgoCOUw5Xj5gNM8=; b=X/Y/u2AQ4iB+wFYtX7o0dhlXcM8ETX71xHbu4Zpa6Nlt2L0JYsO5NuzTPn++HMuRvz UNFFd3NWDhgm7QBPoHooKnafrmDLiWGPzlPBgeyEwdfB59oI6eTiwbNvqQ5V0lAEMkCP COfunNE3SoGhh1GN3c3maWGc+7MTzafTd8yragxztg4aj/nvPPpW2xui1m2flyl2pgPk pT/SSAyKIbnYILV7q35AlrcUSREtzYlokglKhHBY/mJmnj/z/bez+4s4q4DdBncDJOvY nUxR6nZCh9L6qlKL2RF4EGPwdAOhp9xv/+zriPMIZc3HjI7u4iuv6eUvmpKWLxHysHJF i2mg==
X-Gm-Message-State: AG10YOSOPh/O7iq+rNlrvV3waM0rBcEo655xXLtENwYDx9F52rxng4IXXkSzsXw9mNfo0RoUAEYQrjbJGDWc2YFBqnVsVEU7
X-Received: by 10.140.93.166 with SMTP id d35mr16645320qge.29.1455899870479; Fri, 19 Feb 2016 08:37:50 -0800 (PST)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id u191sm1751770qka.2.2016.02.19.08.37.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 08:37:50 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u1JGbmCZ006693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 11:37:48 -0500
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 19 Feb 2016 11:37:48 -0500
From: "Blacka, David" <davidb@verisign.com>
To: Brian Haberman <brian@innovationslab.net>
Thread-Topic: [Technical Errata Reported] RFC5155 (4622)
Thread-Index: AQHRaezQyDYX0XHghE+hgPNTkIPv7J8zz5GAgAAYK4A=
Date: Fri, 19 Feb 2016 16:37:47 +0000
Message-ID: <354ECEF6-49FA-4819-8FA5-9F9AC9116B0A@verisign.com>
References: <20160218013620.0ABC6180209@rfc-editor.org> <56C7309D.8080603@innovationslab.net>
In-Reply-To: <56C7309D.8080603@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/signed; boundary="Apple-Mail=_7EB03420-E23C-47E9-B733-014C235EF8BA"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/2ym7kazL2xXXT_DSrayyL5YVYZ0>
Cc: "geoff-s@panix.com" <geoff-s@panix.com>, "dnsext@ietf.org" <dnsext@ietf.org>, =?utf-8?B?w5NsYWZ1ciBHdeKIgm11bmRzc29u?= <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 16:37:57 -0000

> On Feb 19, 2016, at 10:11 AM, Brian Haberman <brian@innovationslab.net> wrote:
> 
> Does anyone have an opinion on the validity of this erratum? It seems
> like a reasonable clarification in my reading.

The clarification looks correct and reasonable to me.

> 
> 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
>> 
> 

--
David Blacka                          <davidb@verisign.com> 
Distinguished Engineer                Verisign Product Engineering