DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
Note: This ballot was opened for revision 13 and is now closed.
(Mark Townsley) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
(Sam Hartman) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2007-05-22 for -** No value found for 'p.get_dochistory.rev' **)
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.
(Cullen Jennings) No Objection
(Jon Peterson) No Objection
(Tim Polk) (was Discuss) No Objection
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.)