First, -06 addresses all of the comments on the -03 version that I sent in August, and is generally a much better document. Thanks to Scott for keeping up with the details.
I've split my comments on -06 into substantive (protocol) and editorial. First the substantive ones: Section 2: "... the key data SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757." I'd like to see this be a 2119 MAY -- RFC3757 does not say SHOULD, and this document does not document the need for the 2119 SHOULD. Section 2.1.2: It's still not clear exactly how the <secDNS:infData> element's sDate, eDate and vInterval should be used: in particular, none of these seem to specify a desired RRSIG lifetime. Perhaps sDate and eDate are intended to do that, though it's likely that a DNSKEY will be in use for far longer than the requested signing interval -- perhaps another field <maxRRSIGlifetime> is needed? This way a client could say: don't publish this DS until time X, use an RRSIG lifetime no more than 3 days, resigning the DSset every day, and quit publishing this DS after 30 days. The security considerations, in the sixth paragraph, talks about some revokation operations that makes no sense to me. First, it says "...a client should either remove the compromised key...". 'client' should be clarified -- do you mean "the child zone"? And if a DNSKEY is removed without removing the corresponding DS, bad things happen. The next suggestion is to remove "the DNSSIG on the DS" (sic). If the RRSIG(DS) is removed, that should throw an error UNLESS the NSEC is also updated to show no DS at the delegation. In other words, this section needs serious work. Miek and Olaf's DNSSEC operations draft may have useful words. Earlier in the security considerations, in the third paragraph, is the requirement: "...provisioning of public key information MUST only be done after the identities of both parties have been confirmed...". I can understand a need to authorize (but not necessarily identify) the client, but why is there any need to identify the server? Would bad thing could happen if you're talking to the wrong server? And in the seventh paragraph of the security considerations, I don't understand the need for a two-step process. Why not just mark clientHold? Or is this section really trying to address the rapid removal of the secure bits (the DS), but not the delegation? Editorial comments: This document uses the phrase "DNS security extensions" throughout. I'd like to see "DNSSEC" appear somewhere, preferably in the Abstract. Drop references to RFC3008, 3090, 3658, and 3757 -- all are obsoleted by DNSSECbis. Add a reference to the DNSSECbis Intro doc. Section 1, last sentence: consider explicitly saying "DS resource records" rather than just "DNS resource records". Section 1.1 " Indentation and white space in examples is provided only to illustrate element relationships and is not a REQUIRED feature of this protocol." This use of 2119 language seems odd to me. Secion 2.1 uses the words "delegation zone" and "delegated zone". I'm more accustomed to seeing "parent" and "child". -- Sam . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
