Re: [Technical Errata Reported] RFC5155 (4622)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4633314262653613324==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D5155&eid=3D4622
>=20
> --------------------------------------
> Type: Technical
> Reported by: Robert Edmonds <[email protected]>
>=20
> Section: 7.2.8
>=20
> Original Text
> -------------
> 7.2.8.  Responding to Queries for NSEC3 Owner Names
>=20
>    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.
>=20
>    If the following conditions are all true:
>=20
>    o  the QNAME equals the owner name of an existing NSEC3 RR, and
>=20
>    o  no RR types exist at the QNAME, nor at any descendant of QNAME,
>=20
>    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.
>=20
>=20
> Corrected Text
> --------------
> 7.2.8.  Responding to Queries for NSEC3 Owner Names
>=20
>    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.
>=20
>    If the following conditions are all true:
>=20
>    o  the QNAME equals the owner name of an existing NSEC3 RR, and
>=20
>    o  no RR types exist at the QNAME besides NSEC3, nor at any
>       descendant of QNAME,
>=20
>    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.
>=20
>=20
> Notes
> -----
> If the QNAME is equal to the owner name of an existing NSEC3 RR, then t=
he NSEC3 RR type itself will exist at the QNAME, and the second condition=
 will always be false.
>=20
> 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.=20
>=20
> --------------------------------------
> 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
>=20


--sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWxzCiAAoJEBOZRqCi7goqn6kH/0Qs1MOkWJvDdGJSMLKoF8lv
ItZV6ijIAHO/slVtqKaUBMe0mMPJhhRLtnP6OtnBqInJJXMHf54cVw2YdNiEJYfy
S7gNifT2vwvprp/szpBNG/hubHNLdX4d1BrFc+CT9COYSfIKVfr7WupL8lNMBOsf
S1pFQDGlODsvCjJFTFLFP5x8h4Fwr5fNzJm1ZmpN5EVyZrpqvKj/UQ1zvPYhM2yB
Vi3dCIA1Zkpkwddxwk7XlR4JtM4bjqebPpNm6rxc70ZurkFSFOIrDXAuluszrlJ8
xIQ0YxPCNjEvwRreJkKHkSLmfzreP3jAA1Wju6vSOT4raB1IgYwfWmbtDKMaiOM=
=rmA6
-----END PGP SIGNATURE-----

--sQ1IMu4KU3EiTcf0R9xBCbTLi9REqcqvG--


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

--===============4633314262653613324==--