[Last-Call] Secdir last call review of draft-ietf-dnsop-dnssec-bcp-03

[Catherine Meadows via Datatracker <[e-mail]>]

Reviewer: Catherine Meadows
Review result: Has Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with nits

This draft describes the various DNS security extensions, collectively known as
DNSSEC.  It gives a brief description of the DNSSEC documents, along with a
discussion of their importance and relevance.  The purpose of this draft
twofold.  One is it to make it easier for readers to learn about DNSSEC by
providing the a single source that identifies and describes the relevant
documents.  The other is to move DNSSEC to Best Current Practice Status.

I found the document well written, well organized, and informative.  The
documents are clearly ordered by category (Core, Core Additions, Additional
Cryptographic Algorithms, Extensions to DNNSEC, and Additional Documents of
Interest), and the reader is advised of their relevance.  That is, some RFCs
are of limited importance because the features they describe have not been
widely implemented.  It looks it could be very useful to someone starting to
learn about DNSSEC.

The Security Considerations section consists of the statement that the security
considerations from all of the RFCs referenced in this document applies here. 
I certainly agree with that.

I found one thing that could use improving:

The descriptions given in the additional documents of interest section all seem
to be quotations from the documents described.  In most cases this worked well,
but  I found the description of RFC4470 a little puzzling.  It says that the
RFC "describes how to construct DNSSEC NSEC resource records that cover a
smaller range of names than called for by [RFC4034]".

  All the other descriptions mentioned have to do with some security-relevant
  topic, but it is hard to see what the security relevance of this is without
  more information.  In this case, it might be helpful to include the next
  sentence, which is
“By generating and signing these records on demand, authoritative name servers
can effectively stop the disclosure of zone contents  otherwise made possible
by walking the chain of NSEC records in assigned zone.”

This is still a little opaque, but then at least the reader should understand 
that the reason this document is relevant is that it prevents an attacker from
learning all the names  in a zone.