Protocol Modifications for the DNS Security Extensions
Note: This ballot was opened for revision 09 and is now closed.
(Ted Hardie) Yes
(Allison Mankin) Yes
(Thomas Narten) Yes
(Harald Alvestrand) No Objection
Comment (2004-09-27 for -)
Reviewed by Spencer Dawkins, Gen-ART This is very close to the limit for a DISCUSS, given the lack of clarity in the obsoletes/updates section..... but I'm just giving the comment for now. Spencer's review: My perspective: not a Genius of DNS, reading for ease of use of the specifications. The good news: All three of these documents are of high quality. PROTOCOL and RECORDS are very close. I have one question - these two documents, taken together, describe the DNSSEC protocol workings - why do they have two different security sections? (Also, neither matches INTRO's security section, but that makes more sense to me - it's probably OK for INTRO to take a broader view.) All three documents already share a single Acknowledgements section, and making sure security considerations are consistent and complete is a lot more important. If these sections are combined into one occurance, it would be OK to do the same thing with IANA considerations. But everything else for PROTOCOL and RECORDS is Auth-48. The bad news: INTRO is "On the Right Track, but Still Needs Work". - I can't imagine the RFC Editor or the average reader getting what's obsoleted and what's updated right, based on the Introduction. What could "this document and its two companions update AND obsolete" possibly mean? This section needs a lot more clarity. - In Section 3, "These services protect against MOST of the threats to the Domain Name Service described in" - the authors understand what this means a lot better than almost anyone reading it; this is the last chance to clearly spell out what's still an exposure. - NIT - It would be nice to spell out what each record type is at the top of page 8, when they are introduced. The authors spell them out later, but this is the first place they appear. - Top of page 9 - this paragraph takes forever to FINALLY say "Therefore the receiver must be configured with at least one trust anchor" in a very confusing path along the way. The entire paragraph, to this point, could be chopped and it would be an improvement. - Section 6 - there's some discussion about problems with recursive name servers and proxies, but the problem really seems to be about NATs. Which is it? Just needs to be clearer in the second paragraph. - NIT - Section 7 - It would be nice to show references for SIG(O) and TSIG in the second paragraph. It would be nice to spell out "AD bit" in the third paragraph. PROTOCOL NITS - Last sentence of the abstract - does this document obsolete all updates to RFC 2335? If so, better name them out if we expect the RFC Editor to get this right (and the readers to understand it). (Same comment applies to RECORDS). - Starting in 3.2.2 there are a few (at least a couple) mentions of the "sense of the CD bit". I have no idea what this means, unless it's the SETTING of the CD bit. Is this normal terminology in the Land of DNS? - Section 4.2 - s/strips of/strips off/ - Section 5.6, first paragraph - s/example the/example of the/ RECORD had no NITS, except for the "last sentence of the abstract" (same NIT as PROTOCOL). The authors deserve special thanks for the excellent examples in PROTOCOL and RECORDS.
(Steven Bellovin) No Objection
Comment (2004-09-23 for -)
A *very* nice set of documents. I'd almost want the same treatment for 1034/1035 and their updates, but I'm afraid I'd be lynched for suggesting it... Some minor comments. draft-ietf-dnsext-dnssec-protocol-08.txt Section 4.1: a pointer should be added to Section 3 of RFC 3226, noting that on IPv6 packets over 1K SHOULD be fragmented unless the PMTU is known. draft-ietf-dnsext-dnssec-protocol-08.txt Section 4.7: it occurs to me that perhaps there should be some text explicitly permitting caching the result of a signature check, regardless of whether it suceeded or failed. That is, the input would be an octet string and a public key; the output would be a yes/no answer. If an RRset including RRsig was an octet-for-octet match for the cached version, and the public key was the same, the result of doing the hash and exponentiation will be the same. It might (repeat, might) be more CPU-efficient to store this, rather than redoing the calculation. This is independent of the RRset TTL, though a change in RRset's octet string representation would be grounds for deleting that entry from the cache. (This is an implementation efficiency issue; I suggest it only because of the language warning against caching signatures past the TTL expiration. This also applies to 8.1 of draft-ietf-dnsext-dnssec-intro.) draft-ietf-dnsext-dnssec-records: 3.2: add a note about YYYYMMDDHHmmSS being exactly 14 digits, and thus distinguishable from any 32-bit number
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Scott Hollenbeck) (was No Record, Discuss) No Objection
This is a very nicely written set of documents! draft-ietf-dnsext-dnssec-records-09: in all of the following I'm assuming that the values described are NOT octal since one of the values (48) clearly isn't a valid octal number. An RFC Editor note would be an appropriate if others agree that this clarity would be helpful. Section 2, "The Type value for the DNSKEY RR type is 48": please note if "48" is to interpreted as a decimal or hexadecimal number. Section 3, "The Type value for the RRSIG RR type is 46": please note if "46" is to interpreted as a decimal or hexadecimal number. Section 4, "The type value for the NSEC RR is 47": please note if "47" is to interpreted as a decimal or hexadecimal number. Section 5, "The type number for the DS record is 43": please note if "43" is to interpreted as a decimal or hexadecimal number. Section 7: it may be helpful to note here that type values are traditionally represented as decimal numbers. I know this is common knowledge among experienced implementers, but it might not be so clear to a newbie.
(Russ Housley) No Objection
Comment (2004-09-24 for -)
Section 5.2 of draft-ietf-dnsext-dnssec-protocol-08 says: : : A strong cryptographic digest algorithm ensures that an adversary can : not easily generate a DNSKEY RR that matches the digest. : It would be more correct to say: Use of a strong cryptographic digest algorithm ensures that it is computationally infeasible for an adversary to generate a DNSKEY RR that matches the digest. Section 2 of draft-ietf-dnsext-dnssec-records-10 says: : : A resolver can then use the public key to authenticate signatures : covering the RRsets in the zone. : The RRsets are authenticated, not the signatures. Therefore, it would be better to say: A resolver can then use the public key to validate signatures covering the RRsets in the zone, and thus authenticate them.
(David Kessens) No Objection
Comment (2004-09-27 for -)
Comments received from the ops directorate by Pekka Savola: draft-ietf-dnsext-dnssec-intro-12.txt: Security considerations lists a number of threats, but does not discuss whether they have been fixed or mitigated at all (e.g., relating to dynamic updates and signing) [possibly in other documents]. It might not hurt to be a bit more explicit on this. [Similarly, maybe some of this text could be included in the DNS security analysis document as well...] draft-ietf-dnsext-dnssec-protocol-08.txt: A couple of relatively minor comments. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. ==> shouldn't this doc also obsolete some of these other documents whose only purpose was to update 2535? 4.1 EDNS Support A security-aware resolver MUST include an EDNS [RFC2671] OPT pseudo-RR with the DO [RFC3225] bit set when sending queries. A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST advertise the supported message size using the "sender's UDP payload size" field in the EDNS OPT pseudo-RR. ==> I'm slightly concerned by this. It seems to mandate that the implementations MUST advertise the (maximum) supported value, not necessarily the value they deem to be best (e.g., if this would be tied to the PMTU), or the one configured by the administrator. Seems like a wording issue..
(Jon Peterson) No Objection
Comment (2004-09-27 for -)
Great documents, yes. There are two terms used throughout the document set that I think could stand to have a strong definition (perhaps in Section 2 of dnssec-intro): "zone apex" and "authoritative RRsets". I'm sure the authors feel that both of these terms are in common use in the DNS community. However, this document set introduces a lot of MUST-strength language that depends on the understanding of these terms; consider the 2nd to last paragraph of dnssec-protocol 2.2 for an example of both, and look to the first sentence of 2.2 to see why a good understanding of these terms is necessary to avoid contradictory interpretations. I have already experienced one reader using the first sentence of 2.2, for example, to argue that NS records are always signed, presumably because of their interpretation of 'authoritative'. I don't think that the description of 'authoritative RRsets' in rfc1034 4.2.1 can serve as a precise enough definition, anyway. So, please do provide either a pointer to a place where these terms are defined, or provide a definition strong enough that the meaning of these MUST statements will be clear.