Thanks for reading the document again, Sam. Whys and what-fors below. -Scott-
> -----Original Message----- > From: Samuel Weiler [mailto:[EMAIL PROTECTED] > Sent: Monday, January 24, 2005 5:58 PM > To: [email protected] > Cc: Scott Hollenbeck > Subject: Re: [dnsop] EPP-DNSSEC Document Updates > > > 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. This text exists at the request of Ed Lewis. Ed, what say you? Would a MAY be sufficient? > 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. I don't have a strong feeling wither way about the maxRRSIGlifetime thought above, but you have the intent correct. s/eDate describe the client's preference for the start and end dates of DS and RRSIG publication in the parent zone; vInterval is the client's preference for the parent to regenerate the RRSIG every "X" units. What text would make that purpose more clear to you? > 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. Darn, I need to remove that "remove the compromised key". That doesn't make sense now that the RRSIG stuff is gone. > 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. Frankly I'd rather reword the suggestion to make it EPP-specific instead of DNSSEC-specific. Maybe a reference to Miek and Olaf's doc would be better. > 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? A needed urgent update might not get propagated. > 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? Hmm, I suppose it could be either/or, depending on what the child really wants. Yes, that should be clarified. > 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". I'll take care of these. -Scott- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
