Subject: [Gen-art] Gen-ART review of draft-ietf-dnsext-nsec3-10

From: <[email-masked]>
Date: Fri, 18 May 2007 15:06:50 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call 
comments you may receive.

Document: draft-ietf-dnsext-nsec3-10
Reviewer: Pasi Eronen
Review Date: 18 May 2007
IETF LC End Date: 23 May 2007
IESG Telechat date: 24 May 2007

Summary: This draft is basically ready for publication, but has 
nits that should be fixed before publication.

Comments:

This is a very complex document, and quite difficult to understand for
someone who's not intimately familiar with the existing DNSSEC specs
(like myself). Thus, my review is quite superficial...

Some minor suggestions for improvement:

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.

Best regards,
Pasi

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Roy Arends <[email-masked]>
Date: Wed, 23 May 2007 12:44:52 +0200

> Is there a reason why the existing registry for DS RR hash algorithms

Yes. The seperation was a result of a discussion that lead to "issue 22: 
Defining new hash algorithms":

Initially, we'd piggyback on the registry for DS RR hash algorithms. This 
lead to a number of concerns:

a) Operators might get the impression that if a new hash algorithm is 
added to the DS registry, then it is automatically defined for use in 
NSEC3. 
b) The desirable criteria for a DS digest algorithm and an NSEC3 hash 
algorithm are not exactly the same. For instance, NSEC3 is less sensitive 
to the second pre-image resistance property of a hash.
In fact, algorithms that would simply not be acceptable for DS may be 
totally fine for NSEC3 (e.g., MD5.)
c) There are things that must be defined about how a hash works with NSEC3 
before it can be successfully used. For instance, if the hash length is 
longer that 63 characters in base 32, then the hash must be split across 
multiple labels. The consequences of this will no doubt require a 
significant amount of specification, possibly modifying the current NSEC3 
specification.

Hence the decision to split.
 
> instead of just saying "it depends".

I will add an example.
 
> in the example queries/answers, but wouldn't hurt repeating them...).

I'll add that too. 
 
> containing MUST or SHOULD keywords. Probably this should be somewhere

I'll raise it with the other authors, but I think you have a point.

> way, this section needs clarification.

That's historic stuff. Will remove.

Thanks Pasi

Roy