DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
draft-ietf-dnsext-nsec3-13
Yes
(Mark Townsley)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 13 and is now closed.
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-05-22)
Unknown
From the Gen-ART Review by Pasi Eronen: 1) This document creates a new registry for NSEC3 RR hash algorithms. Is there a reason why the existing registry for DS RR hash algorithms can't be used? 2) Section 10.1: it would be useful to give a numerical example of what the maximum length is (for say, "foo.example.com" zone and SHA-1), instead of just saying "it depends". 3) Appendix A: it would be useful if the example zone contained a list of hashes-vs-names as comments (they're included later in the example queries/answers, but wouldn't hurt repeating them...). 4) Section C.1 seems to be in wrong place. Given its location, I would expect to find only some background information, not sentences containing MUST or SHOULD keywords. Probably this should be somewhere earlier in the document? 5) I found Section C.2.3 very confusing. It's not clear whether this section describes a feature of the protocol, or a feature that was proposed but was not included (and design rationale why not). Either way, this section needs clarification.
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2007-05-21)
Unknown
Appendix C.1 begins with the statement: "Augmenting original owner names with salt before hashing increases the cost of a dictionary of pre-generated hash-values." It would be helpful if this section explained that including a salt, regardless of size, does not affect the cost of constructing the NSEC3 RRs using the method outlined in section 7.1. (It does, however, increase the size of the NSEC3 RR. That should also be noted.)