Re: [Technical Errata Reported] RFC5155 (4622)
Ben Laurie <[email protected]> Sat, 20 Feb 2016 20:43:04 +0000
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <CAG5KPzySL64MJw5RsRMzgTcAorWkmB=zHpuNwpKt65wO2izLKg@mail.gmail.com> |
--===============3897652626197009043== Content-Type: multipart/alternative; boundary=001a11c3726a7e4545052c39a5af --001a11c3726a7e4545052c39a5af Content-Type: text/plain; charset=UTF-8 Me, too, though it could be more economically expressed as "no _other_ RR types exist...". On 19 February 2016 at 16:37, Blacka, David <[email protected]> wrote: > > > On Feb 19, 2016, at 10:11 AM, Brian Haberman <[email protected]> > 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 <[email protected]> > >> > >> 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 <[email protected]> > Distinguished Engineer Verisign Product Engineering > > > > > > --001a11c3726a7e4545052c39a5af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Me, too, though it could be more economically expressed as= "no _other_ RR types exist...".</div><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">On 19 February 2016 at 16:37, Blacka, David = <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a>></span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"><span class=3D""><br> > On Feb 19, 2016, at 10:11 AM, Brian Haberman <<a href=3D"mailto:bri= [email protected]">[email protected]</a>> wrote:<br> ><br> > Does anyone have an opinion on the validity of this erratum? It seems<= br> > like a reasonable clarification in my reading.<br> <br> </span>The clarification looks correct and reasonable to me.<br> <div><div class=3D"h5"><br> ><br> > Brian<br> ><br> > On 2/17/16 8:36 PM, RFC Errata System wrote:<br> >> The following errata report has been submitted for RFC5155,<br> >> "DNS Security (DNSSEC) Hashed Authenticated Denial of Existen= ce".<br> >><br> >> --------------------------------------<br> >> You may review the report below and at:<br> >> <a href=3D"http://www.rfc-editor.org/errata_search.php?rfc=3D5155&= amp;eid=3D4622" rel=3D"noreferrer" target=3D"_blank">http://www.rfc-editor.= org/errata_search.php?rfc=3D5155&eid=3D4622</a><br> >><br> >> --------------------------------------<br> >> Type: Technical<br> >> Reported by: Robert Edmonds <<a href=3D"mailto:[email protected]= ">[email protected]</a>><br> >><br> >> Section: 7.2.8<br> >><br> >> Original Text<br> >> -------------<br> >> 7.2.8.=C2=A0 Responding to Queries for NSEC3 Owner Names<br> >><br> >>=C2=A0 =C2=A0The owner names of NSEC3 RRs are not represented in th= e NSEC3 RR<br> >>=C2=A0 =C2=A0chain like other owner names.=C2=A0 As a result, each = NSEC3 owner name is<br> >>=C2=A0 =C2=A0covered by another NSEC3 RR, effectively negating the = existence of<br> >>=C2=A0 =C2=A0the NSEC3 RR.=C2=A0 This is a paradox, since the exist= ence of an NSEC3 RR<br> >>=C2=A0 =C2=A0can be proven by its RRSIG RRSet.<br> >><br> >>=C2=A0 =C2=A0If the following conditions are all true:<br> >><br> >>=C2=A0 =C2=A0o=C2=A0 the QNAME equals the owner name of an existing= NSEC3 RR, and<br> >><br> >>=C2=A0 =C2=A0o=C2=A0 no RR types exist at the QNAME, nor at any des= cendant of QNAME,<br> >><br> >>=C2=A0 =C2=A0then the response MUST be constructed as a Name Error = response<br> >>=C2=A0 =C2=A0(Section 7.2.2).=C2=A0 Or, in other words, the authori= tative name server<br> >>=C2=A0 =C2=A0will act as if the owner name of the NSEC3 RR did not = exist.<br> >><br> >><br> >> Corrected Text<br> >> --------------<br> >> 7.2.8.=C2=A0 Responding to Queries for NSEC3 Owner Names<br> >><br> >>=C2=A0 =C2=A0The owner names of NSEC3 RRs are not represented in th= e NSEC3 RR<br> >>=C2=A0 =C2=A0chain like other owner names.=C2=A0 As a result, each = NSEC3 owner name is<br> >>=C2=A0 =C2=A0covered by another NSEC3 RR, effectively negating the = existence of<br> >>=C2=A0 =C2=A0the NSEC3 RR.=C2=A0 This is a paradox, since the exist= ence of an NSEC3 RR<br> >>=C2=A0 =C2=A0can be proven by its RRSIG RRSet.<br> >><br> >>=C2=A0 =C2=A0If the following conditions are all true:<br> >><br> >>=C2=A0 =C2=A0o=C2=A0 the QNAME equals the owner name of an existing= NSEC3 RR, and<br> >><br> >>=C2=A0 =C2=A0o=C2=A0 no RR types exist at the QNAME besides NSEC3, = nor at any<br> >>=C2=A0 =C2=A0 =C2=A0 descendant of QNAME,<br> >><br> >>=C2=A0 =C2=A0then the response MUST be constructed as a Name Error = response<br> >>=C2=A0 =C2=A0(Section 7.2.2).=C2=A0 Or, in other words, the authori= tative name server<br> >>=C2=A0 =C2=A0will act as if the owner name of the NSEC3 RR did not = exist.<br> >><br> >><br> >> Notes<br> >> -----<br> >> If the QNAME is equal to the owner name of an existing NSEC3 RR, t= hen the NSEC3 RR type itself will exist at the QNAME, and the second condit= ion will always be false.<br> >><br> >> Instructions:<br> >> -------------<br> >> This erratum is currently posted as "Reported". If neces= sary, please<br> >> use "Reply All" to discuss whether it should be verified= or<br> >> rejected. When a decision is reached, the verifying party (IESG)<b= r> >> can log in to change the status and edit the report, if necessary.= <br> >><br> >> --------------------------------------<br> >> RFC5155 (draft-ietf-dnsext-nsec3-13)<br> >> --------------------------------------<br> >> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: DNS = Security (DNSSEC) Hashed Authenticated Denial of Existence<br> >> Publication Date=C2=A0 =C2=A0 : March 2008<br> >> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Laurie, G. = Sisson, R. Arends, D. Blacka<br> >> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STAND= ARD<br> >> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : DNS Exten= sions<br> >> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Inte= rnet<br> >> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF<br> >> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG<br> >><br> ><br> <br> </div></div>--<br> David Blacka=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:[email protected]">davi= [email protected]</a>><br> Distinguished Engineer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Verisign Product Engineering<br> <br> <br> <br> <br> <br> </blockquote></div><br></div> --001a11c3726a7e4545052c39a5af-- --===============3897652626197009043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext --===============3897652626197009043==--