Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

神明達哉 <jinmei@wide.ad.jp> Wed, 21 December 2016 19:34 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3F12956E for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 11:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkHA5goTg-zB for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 11:34:54 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDCB12947D for <dnsop@ietf.org>; Wed, 21 Dec 2016 11:34:53 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id n21so86866877qka.3 for <dnsop@ietf.org>; Wed, 21 Dec 2016 11:34:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=306qncbC+6EIFj5sxCXYzRMeTHUdeWS1cN4RPatP92o=; b=N32IA+WYTelHWbTm3Ncyg2m5Xv7+dtEqsj2qpwuCP4/B+fNExngBx7SGebokxtjwB1 sGPnZ56zpN3lzzJX4rYH2+PxugPR/Nc97KRSSwYk16dn50wfq0sqn+hiCpHw7PZeT1FY AHfpLPCJTcd4ZYGZIVwjg5VTIfTpu/IRre2Hnno6rKCGyrRzVaP93orgb4SqsT7bMLGH oBmlcXVu8dZqfdrfZ4u4lHy4nuPf5v5mbo96G+cpwIUDhXCDADDoce8Ef69nWpxyfbcW O2a1NAKOZa7Poke6Ednf5L54LyybHzX1pU1xMDRVBBaYswHvI0vQaun5ooT46fw6uVVn DYvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=306qncbC+6EIFj5sxCXYzRMeTHUdeWS1cN4RPatP92o=; b=kNyGDgO1z62Tke+J5LL8E1ChxDpbtnmPMLOsIm4qvjAf6gLwenxb3ZRukc7F0CckQd WbmKkKakdrdpbjUtrDbgVDLYbjHZTRaZfaWS6MZ9HZYvMEAVAE9PMbXZBp1NsoGps1bz jRB35HoLaB/42D2bRAdj39lk9DV7UjIye3wYM6Gmqf7dg5/NxAoELnkAlcNzc9obIDRm gAQeLSlUL6ZfotPbKCzbdDJqoUALxshqiOixYmoSlLyUH+FX0EJngZ0/rVzT4AiEKKGm lAtTM5rLvBYMpAgTRFVL6+mxfvnwcppySnGQlsISZlgQlfzAuc/QFj+D3Nd5Ou5d6hjs wA8Q==
X-Gm-Message-State: AIkVDXIuzgfTboEFYkrFK9lR7E+gD4HSqjfdZ4sXGMqWjPAR6p5f5aqO/qs+J0rJU7uZi9AIKwWo4iGNT72R/A==
X-Received: by 10.55.64.69 with SMTP id n66mr6484293qka.20.1482348892915; Wed, 21 Dec 2016 11:34:52 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.200.51.154 with HTTP; Wed, 21 Dec 2016 11:34:52 -0800 (PST)
In-Reply-To: <CADyWQ+EJ0LO=pU-yUdEHwC3aP5KdXxsnD9kEvmmTeAoe0BxK3A@mail.gmail.com>
References: <CADyWQ+EJ0LO=pU-yUdEHwC3aP5KdXxsnD9kEvmmTeAoe0BxK3A@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, 21 Dec 2016 11:34:52 -0800
X-Google-Sender-Auth: e9AyQzPSkF2C1ec45yLtCGH1zjQ
Message-ID: <CAJE_bqeVEsPA8ySOGQFB_Q99hyvtzy_1dey7ddwDv+zvdT779Q@mail.gmail.com>
To: tjw ietf <tjw.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lCEW5hef9zmMjKSX4J-KlM3mStY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2016 19:34:56 -0000

At Tue, 13 Dec 2016 14:13:27 -0500,
tjw ietf <tjw.ietf@gmail.com> wrote:

> We felt another formal Working Group Last call was needed, though hopefully
> shorter.
>
> 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 starts a *one* week Working Group Last Call process, and ends at
> midnight 20  December  2016 UTC.

A bit belated, but I've read the 07 version.  I'm not necessarily
opposed to advancing it, but I personally it's better to spend some
more time to bake it.

The main reason is because the latest change to describe the
aggressive use of deduced wildcards with an equal weight is quite
substantial while I suspect many of the reviewers now only gave a
quick sanity check to confirm whether specific technical details are
addressed.  On a relatively fresh read after some period, I found the
07 version somewhat awkward in some places due to the latest change
(specific comments follow).

Similarly, it's not clear to me whether it now includes the idea of
aggressive use of NSEC/NSEC3 for returning NOERROR/NODATA?  I see a
new sentence in Section 4:

   Proof that a type does
   not exist is accomplished by providing a (DNSSEC secured) record
   containing the queried for name, and a type bitmap which does not
   include the requested type.

but, overall, it still seems to only assume the NXDOMAIN type of
negatives (see, e.g, a comment on Section 6 below).  If the intent is
to also support NOERROR/NODATA, I think we need another round of
overall updates (mostly an editorial effort, but not trivial).

Another reason for the wish of having some more discussion is that I
think the described justification for changing the recommendation in
RFC4035 is still weak (although I don't disagree with the change
itself).  Section 4 states:

   We believe this recommendation can be relaxed because, in the absence
   of this technique, a lookup for the exact name could have come in
   during this interval, and so a negative answer could already be
   cached (see [RFC2308] for more background).

But this argument has always been the case including when RFC4035 was
written.  As RFC4035 still made this recommendation...

   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.

...I'd logically expect some new argument that was not true or not
recognized at the time of RFC4035 if we wanted to revise the
recommendation.  Examples of such a new argument include:

- some statistics that shows "a lookup for the exact name comes in
  during this interval" more often than previously expected, so it
  turns out the old recommendation really doesn't help much.
- the benefits of the aggressive use of NSEC(3)/deduced wildcards are
  now considered so big that they outweigh the prudence recommended in
  RFC4035.

I'd like to see something like these with convincing facts or
rationale in Section 4.

Specific comments:

- Title: "Aggressive use of NSEC/NSEC3"

  I think this should now be e.g., "Aggressive use of DNSSEC-validated
  cache" because of the equal weight given to the aggressive use of
  deduced wildcards.  Even if the aggressive use of NSEC/NSEC3 can be
  used as part of steps to use a deduced wildcard aggressively (i.e.,
  to confirm the query name wouldn't exist without the wildcard), the
  aggressive use of deduced wildcard has its own "aggressiveness" with
  its own caveats.  For example, in addition to the case where the
  wildcard-matched name is added to the zone, we also take the risk of
  not returning a negative answer sooner when the wildcard is removed.
  So I think this document should now use both NSEC/NSEC3 (for
  negative) and wildcard (for positive) equally when it says
  "aggressive use of XXX".  The above example suggestion is one
  attempt to do this.  And, if this suggestion makes sense, it should
  apply throughout the document (this is one reason why it's better to
  spend some more time before shipping it).

- Section 4

   queried for name.  In the first example above, if the (DNSSEC
   validating) recursive server were to query for dog.example.com it

  In this context I don't see why this has to be a recursive server.
  I also found some other occurrences of "recursive" when it doesn't
  necessarily have to be a recursive in that context.  It would be
  nice to clean up the terminology issue, but maybe it's too minor
  and/or too subtle.  Since they are now only in examples, the
  additional clarity may not be worth the additional editorial effort.

- Section 6

   Reduced latency:  By answering directly from cache, validating
      resolvers can immediately inform clients that the name they are
      looking for does not exist, improving the user experience.

  This only seems to assume the NXDOMAIN type of negative response.
  It's not necessarily incorrect as it just shows an example benefit,
  but, overall, text like this makes me wonder whether this doc also
  intends to cover the NOERROR/NODATA type of negative.

- Section 11

   Thanks to Mark Andrews for providing the helpful notes for
   implementors provided in Appendix B.
...
   [...].  Mark Andrews also provided the
   helpful notes for implementors (https://www.ietf.org/mail-
   archive/web/dnsop/current/msg18332.html) which we made into
   Appendix B.

  I'm not sure if it's intentional (if it is, that's fine for me), but
  these two sentences are almost a duplicate and can be unified.

--
JINMEI, Tatuya