Note: This ballot was opened for revision 11 and is now closed.
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Comments received from the ops directorate by Pekka Savola:
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...]
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..
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.
My perspective: not a Genius of DNS, reading for ease of use of the
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
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
- 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.
- 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.
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.
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.
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.
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