DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-13

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..

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.

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