At Thu, 22 Sep 2016 08:19:17 -0400,
Tim Wicinski <tjw.ietf@gmail.com> wrote:

> This draft has been worked on and it seems that the Working Group is
> happy with the updates that have been made and I feel it's ready for the
> next step.
>
> This starts a Working Group Last Call for:
>     "Aggressive use of NSEC/NSEC3"
>        draft-ietf-dnsop-nsec-aggressiveuse
>
> Current versions of the draft is available here:
>     https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.

This draft is now in a pretty good shape, but IMO it needs some more
non-trivial discussions, and in that sense I don't think it's ready
for publication as it is.  Specific comments follow.  I'll also try to
answer some of the points I haven't responded to in previous threads.

- (general) this draft still unnecessarily limits the use of this
  technique to *recursive* resolvers.  In my previous comment I
  pointed out that the term "full-service resolver" is too
  restrictive.  The 02 version changes the term to "recursive
  resolver", but that doesn't address the main point of my comment.
  I'll note some specific part of the draft that has this issue, but
  it may not be comprehensive.  If the sense of this comment is
  accepted, the entire draft will have to be carefully examined and
  revised.

- Section 1: s/recursive/validating/

   This document updates RFC 4035 to allow recursive resolvers to use

  Note: the use of "validating resolver" is my suggested change in
  this sense, so I'll consistently use it throughout my comments.  But
  I understand it's not the only way to address the point.

- Section 2

   Many of the specialized terms used in this document are defined in
   DNS Terminology [RFC7719].  In this document we are using the terms
   "recursive resolver" or "recursive server" as a more readable
   alternative to the more formal[RFC7719] "full-service resolver"

  See the general comment.  At least in the context of my previous
  comment, this is not about readability but about applicability, so
  changing "full-service resolver" to "recursive resolver/server"
  doesn't address the point.  My primary suggestion is to just remove
  the second sentence.  Or, if we want to make some note about a
  terminology regarding "resolver", it may be that this document uses
  the term "validating resolver" as it's used in RFC4035.

- Section 3: this section also has an issue of "recursive resolver".
  Although it may not be as critical as other part of the draft since
  it's only used as an example scenario, it's probably better to not
  limit the role of resolver to avoid misleading.  Maybe "recursive
  resolver" is just changed to "validating resolver", and
  "authoritative server" is changed to, e.g., "external servers"
  (meaning either authoritative or or other recursive servers).

- Section 4: s/recursive server/validating resolver/

- Section 4: is this perhaps some leftover and should be removed?

   [RFC4035]; Section 4.5 states:

   For a zone signed with NSEC, it would be possible to use the
   ...

  There doesn't seem to be text starting with "For a zone..." in
  Section 4.5 of RFC4035.  And, even if there's such text, "However,
  such use is discouraged by Section 4.5 of RFC4035." in that context
  is really awkward.

- Section 4

   We believe this
   recommendation can be relaxed because lookups for the specific name
   could have come in during the normal negative cache time and so
   operators should have no expectation that an added name would work
   immediately.  We think that the TTL of the NSEC record is the
   authoritative statement of how quickly a name can start working
   within a zone.

  I'm not necessarily opposed to this claim per se, but IMO it should
  provide some more careful justification.  It's true that "specific
  name could have come in during the normal negative cache time", but
  nsec-aggressiveuse could make such accidental disruption more likely
  to happen.  Even if it should be considered an operational error, I
  believe we should at least note the difference, and, ideally,
  provide an explanation of why it should be still acceptable.  IIRC I
  raised the same point for the cheese shop draft.  I don't remember
  the conclusion at that time, but if it was an introduction of some
  more explanation, the same resolution can apply here.

- Section 5.2

   Implementations SHOULD enable aggressive use of NSEC by default.

  On a fresh re-read of the draft, I'm now not so sure if this is
  clear enough and the requirement is reasonable.  First, does this
  also implies an implementation SHOULD implement aggressive use of
  NSEC?  Secondly, and especially if the answer to the first point is
  'yes', I'm not sure if SHOULD is reasonable.  Since this is just an
  optimization, it may be just up to the discretion of the
  implementor.

- Section 5.4

   Such aggressive use of cached deduced wildcard can be employed
   independently from aggressive use of NSEC.  But, it will be more
   effective when both are enabled since the resolver can determine the
   name subject to wildcard would not otherwise exist more efficiently.

  I've seen a comment in a previous thread that the second sentence
  (I suggested this text) isn't very readable.  I tend to agree, and
  although I suspect there should be a better English writer than me
  to improve it, I wonder this might be better:

   Such aggressive use of cached deduced wildcard can be employed
   independently from aggressive use of NSEC.  However, the resolver
   still needs to determine the name subject to wildcard would not
   otherwise exist.  Aggressive use of NSEC will help determine it
   more effectively.

- Section 5.4: I suspect this is a leftover from a previous version
  and should now be removed:

   Furthermore, when aggressive use of NSEC is enabled, the aggressive
   use of cached deduced wildcard will be more effective.

- Section 6: s/recursive server/resolver/ (or validating resolver)

   Decreased recursive server load  By answering negative queries from

- Section 6:

   The technique described in this document may also mitigate so-called
   "random QNAME attacks", in which attackers send many queries for
   ...

  IMO this paragraph is unnecessarily too verbose.  Now that the
  mitigation effect is just a better-than-nothing kind of measure
  rather than a major sales point of the technique, I don't think we
  have to provide detailed discussions on cases where it may not work
  well, etc (and, however hard we try it, it won't be complete
  anyway).  I'd make it much more concise, e.g.:

   The technique described in this document may also mitigate so-called
   "random QNAME attacks", in which attackers send many queries for
   random sub-domains to resolvers.  As the resolver will not have the
   answers cached it has to ask external servers for each random
   query, leading to a DoS on the authoritative servers (and often
   resolvers).  Aggressive NSEC may help mitigate these attacks by
   allowing the resolver to answer directly from cache for any random
   queries which fall within already requested ranges.  It will not
   always work as an effective defense, not least because not many
   zones are DNSSEC signed at all, but it will still provide an
   additional layer of defense.

 (I also made the "recursive server to resolver" cleanup here).

- Section 7: s/recursive resolvers/validating resolvers/

   |  Once the records are validated, DNSSEC enabled recursive    |
   |  resolvers MAY use wildcards and NSEC/NSEC3 resource records |

  This is also more consistent with the text shown in Section 5, and
  more compatible with RFC4035 itself (in my understanding the RFC
  doesn't unnecessarily limit discussions to recursive servers).

- Section 9

   Aggressive use of NSEC / NSEC3 resource records without DNSSEC
   validation may cause security problems.  It is highly recommended to
   apply DNSSEC validation.

  This paragraph is awkward.  I pointed this out several times, so I
  won't repeat it here - please refer to my previous comments.  One
  possibly new perspective is that this tries to cover cases where
  NSEC or NSEC3 is somehow cached before/without DNSSEC validation and
  note that such records shouldn't be used for the purpose of
  nsec-aggressiveuse.  If so, it might make some sense, but in that
  case it should be totally rephrased to avoid confusion or
  misleading.

--
JINMEI, Tatuya