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

From: tjw ietf <[email-masked]>
Date: Tue, 13 Dec 2016 14:13:27 -0500

All

The process of WGLC for this document engaged the working group and there
was much discussion and several different versions.  It seems that the
authors have addressed everything that has been brought up.

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/

For those looking for the differences, these are the differences between
the document submitted, and the current one:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggressiveuse-02&url2=draft-ietf-dnsop-nsec-aggressiveuse-03

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.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Dec 2016 19:16:37 +0000

The authors think that they have captured / addressed everyone's comments -
if we missed (or misunderstood) anything, it was unintentional.
W

On Tue, Dec 13, 2016, 2:13 PM tjw ietf <[email-masked]> wrote:

> We felt another formal Working Group Last call was needed, though
> hopefully shorter.
>
> 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.
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 14 Dec 2016 13:46:13 +0100

Tim,

On 13-12-16 20:13, tjw ietf wrote:
> All
>
> The process of WGLC for this document engaged the working group and
> there was much discussion and several different versions.  It seems that
> the authors have addressed everything that has been brought up.
>
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/>
>

I think you meant:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggressiveuse-02&url2=draft-ietf-dnsop-nsec-aggressiveuse-07

Best regards,
   Matthijs

---

From: tjw ietf <[email-masked]>
Date: Wed, 14 Dec 2016 07:58:38 -0500

Sigh, I did.

Thank you Matthijs for keeping me honest.

tim

On Wed, Dec 14, 2016 at 7:46 AM, Matthijs Mekking <[email-masked]>
wrote:

>> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggr
>> essiveuse-02&url2=draft-ietf-dnsop-nsec-aggressiveuse-03
>>
>
>
> I think you meant:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggr
> essiveuse-02&url2=draft-ietf-dnsop-nsec-aggressiveuse-07
>
> Best regards,
>   Matthijs
>
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Dec 2016 14:53:00 +0100

On Tue, Dec 13, 2016 at 02:13:27PM -0500,
 tjw ietf <[email-masked]> wrote 

>       draft-ietf-dnsop-nsec-aggressiveuse

I've read -07 and I believe it is OK and ready for publication. All my
(many) remarks have been addressed, I think.

Two details:

> [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to
> using NXDOMAIN information for more effective caching

IMHO, RFC 8020 supersedes draft-vixie-dnsext-resimprove, so it is not
necessary to mention both. If you prefer to do so for historical
completeness, may be you should mention them in the chronological
order?

> As these benefits are only accrued by those using DNSSEC, it is
> hoped that these techniques will lead to more DNSSEC deployment.

This sentence should really be deleted. It seems to imply that DNSSEC
cannot work on its own merits and need extra arguments. "NSEC
aggressive use of caching"'s goal is not to promote DNSSEC, it is to
improve the DNS!

---

From: Bob Harold <[email-masked]>
Date: Thu, 15 Dec 2016 09:37:49 -0500

> aggressive use of caching"'s goal is not to promote DNSSEC, it is to

I would like to respectfully disagree.  I read the sentence as saying that
this adds one more benefit to running DNSSEC, which makes people like me
want to move DNSSEC closer to the top of my priority list.

-- 
Bob Harold

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Dec 2016 14:55:22 +0000

> completeness, may be you should mention them in the chronological
Yup, I think that having them both is useful, both for historical purposes,
but also because resimprove contains much worth reading -- I like you
swapping the order suggestion...

> aggressive use of caching"'s goal is not to promote DNSSEC, it is to
That was certainly not the intent, but rather what Bob had suggested below
-- this adds yet another point to the "how to justify spending the $$$ to
management / bean-counters" list. I *do* understand where you are coming
from, but am not sure how to word something appropriate -- would "These
benefits are only accrued by those using DNSSEC, it is hoped that these
techniques will speed the deployment of DNSSEC validation".
That makes it more clear that DNSSEC is the right thing to do anyway, and
that this just helps us get there faster?

> want to move DNSSEC closer to the top of my priority list.

Yup, that was the intent - many people want to deploy, but need to juggle
priorities, or convince bean-counters why this is the right thing to do.
Waving the security flag makes them shrug, but pointing how this might help
save money gets more management buy-in for the ask.

W
(Yes, I did use "management buy-in for the ask." in an IETF mail. It was
oddly thrilling :-))

--

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 16 Dec 2016 10:05:52 +0100

I have read the -07 version and I think this document is ready for
publication.

I do still think that the end of section 4 and start of section 5 is too
similar and can be combined such that it only quotes RFC 4035 one time.
Perhaps Section 5 can just start with:

5.  Aggressive use of Cache

   This document relaxes the restriction given in Section 4.5 of
   [RFC4035], see Section 7 for more detail.

   If the negative cache of the validating resolver has sufficient...

Best regards,
  Matthijs

On 15-12-16 15:55, Warren Kumari wrote:
> 
> 
> On Thu, Dec 15, 2016 at 9:38 AM Bob Harold <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     On Wed, Dec 14, 2016 at 8:53 AM, Stephane Bortzmeyer
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>          tjw ietf <[email-masked] <mailto:[email-masked]>> wrote
> Yup, I think that having them both is useful, both for historical
> purposes, but also because resimprove contains much worth reading -- I
> like you swapping the order suggestion... 
>  
> 
> That was certainly not the intent, but rather what Bob had suggested
> below -- this adds yet another point to the "how to justify spending the
> $$$ to management / bean-counters" list. I *do* understand where you are
> coming from, but am not sure how to word something appropriate -- would
> "These benefits are only accrued by those using DNSSEC, it is hoped that
> these techniques will speed the deployment of DNSSEC validation".
> That makes it more clear that DNSSEC is the right thing to do anyway,
> and that this just helps us get there faster? 
> 
> 
>     I would like to respectfully disagree.  I read the sentence as
>     saying that this adds one more benefit to running DNSSEC, which
>     makes people like me want to move DNSSEC closer to the top of my
>     priority list. 
> 
> 
> Yup, that was the intent - many people want to deploy, but need to
> juggle priorities, or convince bean-counters why this is the right thing
> to do. Waving the security flag makes them shrug, but pointing how this
> might help save money gets more management buy-in for the ask.
> 
> W
>     [email-masked] <mailto:[email-masked]>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Dec 2016 11:59:15 +0100

On Tue, Dec 13, 2016 at 07:16:37PM +0000,
 Warren Kumari <[email-masked]> wrote 
 a message of 132 lines which said:

> The authors think that they have captured / addressed everyone's
> comments - if we missed (or misunderstood) anything, it was
> unintentional.

One of my comments was not addressed. I would like, in section 10, see
some details about what exactly is implemented by Unbound and Google
Public DNS:

* synthesis of NXDOMAIN from NSEC (obviously; that's the minimum)
* synthesis of NXDOMAIN from NSEC3 (if no opt-out)
* synthesis of NODATA from NSEC/NSEC3
* synthesis of positive answers from wilcards+NSEC
* all of them?

---

From: Ralph Dolmans <[email-masked]>
Date: Tue, 20 Dec 2016 13:18:37 +0100

Hi,

> * synthesis of positive answers from wilcards+NSEC

NSEC reply synthesis is not (yet) implemented in Unbound. I do not know
why it is mentioned in section 10.
I know of the existence of a patch, but that one seems to have flaws and
is incomplete.

Unbound currently uses its negative cache to prove non-existence of DS
records. Not for synthesizing replies (although it is on our road-map
for the very near future).

Regards,
-- Ralph

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Dec 2016 10:14:16 -0500 (EST)

> * synthesis of positive answers from wilcards+NSEC

Do you mean this in the context of RFC 6982? Or do you believe this
needs to go into the RFC?

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Dec 2016 16:22:10 +0100

On Tue, Dec 20, 2016 at 10:14:16AM -0500,
 Paul Wouters <[email-masked]> wrote 
 a message of 16 lines which said:

> Do you mean this in the context of RFC 6982?

No, RFC 7942.

> Or do you believe this needs to go into the RFC?

Certainly not.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Dec 2016 10:29:13 -0500 (EST)

>> Or do you believe this needs to go into the RFC?

Ok, we are talking about the same and are in agreement :)

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Dec 2016 19:38:08 +0000

> * synthesis of positive answers from wilcards+NSEC

The Google Public DNS code is constantly evolving - I'm discussing with the
team lead to see what answers I can provide to the above....
Is this a "nice to know", or do you think it needs to hold up the WGLC? Can
/ should I just remove the section?

W

---

From: 神明達哉 <[email-masked]>
Date: Wed, 21 Dec 2016 11:34:52 -0800

At Tue, 13 Dec 2016 14:13:27 -0500,

>    https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
[...]
> 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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 21:37:20 +0100

On Tue, Dec 20, 2016 at 07:38:08PM +0000,
 Warren Kumari <[email-masked]> wrote 

> team lead to see what answers I can provide to the above....

:-(

> Is this a "nice to know", or do you think it needs to hold up the
> WGLC? Can / should I just remove the section?

To me, it is useful: the goal of this section (RFC 7942) is to inform
people about whether the idea has been tested on the battlefield or
not.

Also, it may help address the remarks by JINMEI, Tatuya
<https://mailarchive.ietf.org/arch/msg/dnsop/lCEW5hef9zmMjKSX4J-KlM3mStY>
(about the fact that NODATA synthesis has not been really seriously
studied).

The fact that it mentioned Unbound for several iterations of the draft
while Unbound actually does not implement the draft seems to indicate
that IETF is not careful enough about "running code" :-(

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 21:53:38 +0100

On Wed, Dec 21, 2016 at 11:34:52AM -0800,
 神明達哉 <[email-masked]> wrote 
 a message of 143 lines which said:

>   deduced wildcards.

Strong +1 to this one. Not sure about the rest of your remarks.