Subject: [DNSOP] Working Group Last Call

From: Tim Wicinski <[email-masked]>
Date: Thu, 22 Sep 2016 08:19:17 -0400

All

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.

It's currently marked as "Proposed Standard", so if folks feel 
differently then please speak up.

This starts a two week Working Group Last Call process, and ends at 
midnight 7 October 2016 UTC.

thanks
tim

---

From: Warren Kumari <[email-masked]>
Date: Thu, 22 Sep 2016 09:40:25 -0400

On Thursday, September 22, 2016, Tim Wicinski <[email-masked]> wrote:

> All
>
> 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.
>
> It's currently marked as "Proposed Standard", so if folks feel differently
> then please speak up.

 And as a quick reminder to readers we made it PS because it updates
RFC4035.

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "John Levine" <[email-masked]>
Date: 22 Sep 2016 15:04:53 -0000

>feels the document is *not* ready for publication, please speak out with 

I think it's ready to publish with one small caveat.  In section 5.1,
the text in the box says "resolvers MAY use NSEC/NSEC3 resource
records" and the text in the next paragraph says "the resolver SHOULD
use NSEC/NSEC3/wildcard records".  There's a similar MAY in the box in
section 7.

The authors SHOULD make up their minds.  Assuming they really believe
this is a good idea, change the MAY's to SHOULD.

R's,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 25 Sep 2016 17:04:11 +0000

On Thu, Sep 22, 2016 at 08:19:17AM -0400,
 Tim Wicinski <[email-masked]> wrote 

>       draft-ietf-dnsop-nsec-aggressiveuse

I like the basic idea and I think the document is good but I would not
like it to be published as it is (-02).

My biggest concern is that it seems the original idea was to mention
only the synthesis of _negative_ replies (NXDOMAIN), _positive_
replies (synthesis from a wildcard) were mentioned for a long time in
the draft but never fully integrated. Section 7 mentions this
synthesis of positive answers but, for instance, the abstract, the
section 1, section 3, the first paragraph of section 5.5, and the
first paragraph of section 9 do not mention the positive answers, but
they should (they seem to assume that only negative caching matters).

Either we need to match the document to put the synthesis of negative
and positive answers on an equal footing, or we should delete the
synthesis of positive answers from wildcards.

Related to this issue is the fact that the proposed updated text for
RFC 4035 is not the same in section 5.1 and in section 7...

Another concern is section 9 which says "Aggressive use of NSEC /
NSEC3 resource records without DNSSEC validation may cause security
problems.  It is highly recommended to apply DNSSEC validation." Not
only it fails to use RFC 2119 but allowing NXDOMAIN synthesis without
DNSSEC validation seems dangerous. Why not a MUST instead of the
current "informal SHOULD"?

Details
*******

IMHO, it should say from the beginning that this document is only for
validating resolvers. (It is not in section 1, for instance.)

Editorial
*********

Section 1 says "This document updates RFC 4035 to allow recursive
resolvers to use NSEC/NSEC3 resource records to aggressively cache
negative answers."  It would be more descriptive, IMHO, to say "This
document updates RFC 4035 to allow recursive resolvers to use
NSEC/NSEC3 resource records to synthetize negative answers from the
information they have in the cache." (It is an aggressive use of the
cache, not aggressive caching.)

Bikeshedding
************

Section 5.2 says "Implementations SHOULD provide a configuration switch to disable
aggressive use of NSEC and allow it to be enabled or disabled per
domain." Such as switch (the per-domain one) seems costly and I would
prefer a MAY here.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 29 Sep 2016 11:32:22 -0700

At Thu, 22 Sep 2016 08:19:17 -0400,

> feels the document is *not* ready for publication, please speak out with

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