Subject: Re: [dnsext] [Technical Errata Reported] RFC4034 (2681)

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 23 Mar 2011 22:57:52 -0400

This errata is also correct,
I ran into this same issue myself.

	Olafur

On 05/01/2011 5:18 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC4034,
> "Resource Records for the DNS Security Extensions".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=2681
>
> --------------------------------------
> Type: Technical
> Reported by: Guillaume Bailey<[email-masked]>
>
> Section: B
>
> Original Text
> -------------
>     The key tag is the same for all DNSKEY algorithm types except
>     algorithm 1 (please see Appendix B.1 for the definition of the key
>     tag for algorithm 1).  The key tag algorithm is the sum of the wire
>     format of the DNSKEY RDATA broken into 2 octet groups.  First, the
>     RDATA (in wire format) is treated as a series of 2 octet groups.
>     These groups are then added together, ignoring any carry bits.
>
>
> Corrected Text
> --------------
>     The key tag is the same for all DNSKEY algorithm types except
>     algorithm 1 (please see Appendix B.1 for the definition of the key
>     tag for algorithm 1).  The key tag algorithm is the sum of the wire
>     format of the DNSKEY RDATA broken into 2 octet groups.  First, the
>     RDATA (in wire format) is treated as a series of 2 octet groups.
>     These groups are then added together with at least 32-bit precision,
>     retaining any carry bits. The carry bits are then added to the result,
>     and finally, only the lower 16 bits of the result are used as the key
>     tag.
>
>
>
> Notes
> -----
> This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning:
>
>      ac += (ac>>  16)&  0xFFFF;
>
> Instructions:
> -------------
> This errata 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.
>
> --------------------------------------
> RFC4034 (draft-ietf-dnsext-dnssec-records-11)
> --------------------------------------
> Title               : Resource Records for the DNS Security Extensions
> Publication Date    : March 2005
> Author(s)           : R. Arends, R. Austein, M. Larson, D. Massey, S. Rose
> Category            : PROPOSED STANDARD
> Source              : DNS Extensions
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Mar 2011 18:01:30 +0100

> I ran into this same issue myself.

I am not an implementer, so I am not sure that what I say here is correct. It sounds like the normative text in Appendix B does not match the presumably normative "reference implementation" in C a few paragraphs later. If so, why does the "reference implementation" win over the C code?

--Paul Hoffman

---

From: Chris Thompson <[email-masked]>
Date: 25 Mar 2011 19:45:11 +0000

On Mar 25 2011, Paul Hoffman wrote:

>I am not an implementer, so I am not sure that what I say here is correct.
>It sounds like the normative text in Appendix B does not match the presumably
>normative "reference implementation" in C a few paragraphs later. If so, why
>does the "reference implementation" win over the C code?

Because it is what everyone has actually implemented? And it's not really
clear which is more "normative", given text like

* It is not necessary to use the following reference code verbatim, but
* the numerical value of the Key Tag MUST be identical to what the reference
* implementation would generate for the same input.

It's bad enough that the tag calculation is a botched version of the
ones-complement checksum in the first place, without trying to change
it at this stage.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 25 Mar 2011 13:50:29 -0400

Perhaps because the reference code is unchanged from RFC 2535 and the
newly synthesized text for RFC 4034 is therefore probably where the
error is?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

On Fri, Mar 25, 2011 at 1:01 PM, Paul Hoffman <[email-masked]> wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 26 Mar 2011 08:06:06 +0100

On Mar 25, 2011, at 8:45 PM, Chris Thompson wrote:

> Because it is what everyone has actually implemented?

That works for me. If it is the case, it should be stated in the Errata report.

--Paul Hoffman