Subject: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

From: Tim Wicinski <[email-masked]>
Date: Sun, 10 Apr 2016 10:18:11 -0400

This was discussed in Buenos Aires Friday morning, but the sense we 
received from the room is that the group should move forward with this 
draft.  While we like the simplicity of Warren and Geoff's cheese-shop 
draft (draft-wkumari-dnsop-cheese-shop), it is basically a simple 
proof-of-concept.    The suggestion was to document the cheese-shop idea 
in this draft.

This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
draft-fujiwara-dnsop-nsec-aggressiveuse

The draft is available here:

https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.  *Speak 
Up* if you have strong opposition to this work.

*More Importantly*
Please also indicate if you are willing to contribute text, review, etc.
We will want several dedicated reviewers on this.

I'm going to make this a short call for adoption, as we've discussed 
this in a few meetings.

This call for adoption ends 17 April 2016.

Thanks,
tim wicinski
DNSOP co-chair

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 10 Apr 2016 12:52:39 -0400

I have read the draft and support its adoption

Olafur

> On Apr 10, 2016, at 10:18 AM, Tim Wicinski <[email-masked]> wrote:
> 
> This was discussed in Buenos Aires Friday morning, but the sense we received from the room is that the group should move forward with this draft.  While we like the simplicity of Warren and Geoff's cheese-shop draft (draft-wkumari-dnsop-cheese-shop), it is basically a simple proof-of-concept.    The suggestion was to document the cheese-shop idea in this draft.
> 
> Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.  *Speak Up* if you have strong opposition to this work.
> 
> *More Importantly*
> I'm going to make this a short call for adoption, as we've discussed this in a few meetings.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Evan Hunt <[email-masked]>
Date: Sun, 10 Apr 2016 19:55:36 +0000

> I have read the draft and support its adoption

+1.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 11 Apr 2016 13:42:54 +0200

Tim,

At 2016-04-10 10:18:11 -0400

> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/

... 

> We will want several dedicated reviewers on this.

I have read the draft, and support the adoption. I will be happy to
offer text, review, and so on going forward.

Cheers,

--
Shane

---

From: Shumon Huque <[email-masked]>
Date: Mon, 11 Apr 2016 08:44:34 -0400

I've read the draft and support its adoption. Will review, etc.

On Sun, Apr 10, 2016 at 10:18 AM, Tim Wicinski <[email-masked]> wrote:

> proof-of-concept.    The suggestion was to document the cheese-shop idea in
> this draft.
>
> by DNSOP, and comments to the list, clearly stating your view.  *Speak Up*
> if you have strong opposition to this work.
>
> *More Importantly*

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 Apr 2016 10:15:43 -0400

>> This call for adoption ends 17 April 2016.
I support adoption.  Will read and review.

Section 7.3 concerns me.  If the range is expanded enough to be useful,
would it then allow zone enumeration?

---

From: 神明達哉 <[email-masked]>
Date: Wed, 13 Apr 2016 11:27:41 -0700

At Sun, 10 Apr 2016 10:18:11 -0400,

> We will want several dedicated reviewers on this.

I've read previous and current versions of the draft.  I support the
adoption of this draft with one condition: IMO its "problem statement"
should be completely revised.  If adopted, I'm willing to review
future versions.

Regarding the problem statement, I believe my comments on a previous
version still stand:
https://www.ietf.org/mail-archive/web/dnsop/current/msg14865.html
(the point about wildcard may warrant more discussion, but that's
relatively minor in the whole context).  The latest version of the
draft seems to try to defend it in that scenario, thereby rather
making it fragile and unnecessarily complicated (see below for some
specific points).

So I think this draft should stop selling the idea as a counter
measure for random subdomain attacks on *recursive servers*.  It may
still have other benefits, such as:

- general possible performance improvement for recursive servers (but,
  as I commented for the cheese-shop draft, I'd like to see measured
  evidence about that).
- possible counter measure for random subdomain attacks on
  *authoritative servers* (and encourage the authoritative operators
  to sign their zones)
- reducing garbage (though not attack) traffic to authoritative
  servers, especially higher level ones such as root.

And I see these are at least worth discussing, and I therefore support
the adoption in that context.

Some specific comments on the 03 version

- Abstract: I suggest revising this on this point (see above):

   responses as well as some level of mitigation of random sub-domain
   attacks (referred to as "Water Torture" attacks).

  by either simply removing it or clarifying that it's mitigation for
  authoritative servers.

- Section 3: IMO this section will have to be completely revised in
  terms of the selling point.  Even if my point about the effect for
  recursive server is refused, this section looks still quite awkward
  since it reads as if this is *the* problem this proposal tries to
  address, while in (e.g.) abstract it rather sounds a weak subset of
  the goals.

- Section 4.2: this may also depend on the goal of the proposal, but
  at this moment I don't think this "SHOULD" is fully justified:

   A full-service resolver implementation SHOULD support aggressive use
   of NSEC and enable it by default.  It SHOULD provide a configuration
   knob to disable aggressive use of NSEC.

  If it's just a possible performance improvement for recursive
  servers, it should be totally up to the implementors choice.  For
  other purposes such as (helping) attack mitigation for authoritative
  servers or reduce garbage traffic to the root, some stronger
  requirement level may make sense, but I'd like to see more empirical
  evidence before making the requirement.

- Section 4.5

   Even if a wildcard is cached, it is necessary to send a query to an
   authoritative server to ensure that the name in question doesn't
   exist as long as the name is not in the negative cache.

   When aggressive use is enabled, regardless of description of
   Section 4.5 of [RFC4035], it is possible to send a positive response
   immediately when the name in question matches a NSEC/NSEC3 RRs in the
   negative cache.

  I don't understand the second paragraph.  I also don't understand
  how the first paragraph is related to the second.  I'm not sure if
  it's only me, but I'd like to see more explanation here.

- Section 5.1: IMO, this is an example that makes the document fragile
  by trying to defend it as an attack mitigation.  If we say something
  like this:

   This draft proposes that the CD bit may be ignored to support
   aggressive negative caching when the full-service resolver is under
   attacks with CD bit set.

  It's useless unless we also specify how to detect the resolver is
  under an attack.  And, if we can reasonably detect that (which I
  guess is possible) we might not necessarily need nsec-aggressiveuse
  for mitigation.  When it's under an attack, other general counter
  measures such as rate limiting can be justified and probably
  sufficient.  My personal suggestion is to stop the idea of defending
  it as an attack mitigation, and simply note the implication of the
  CD bit as a fact.  It will not immediately make this proposal
  useless for other general cases, since such queries would be
  relatively much rare.

- Section 5.2: ditto.  I suggest simply removing this section.

- Section 9: I don't understand this:

   Aggressive use of NSEC/NSEC3 resource records without DNSSEC
   validation may cause security problems.

  Specifically what does "without DNSSEC validation" mean?  Something
  like a case where a validating resolver receives an NSEC/NSEC3 and
  uses that information without DNSSEC-validating it?  If so, it's
  simply invalid per protocol whether the use is "aggressive" or not.
  So I don't see the need for stating that here.  If this means
  something else, I didn't get it and would like to see more
  explanation.

--
JINMEI, Tatuya

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Apr 2016 16:13:44 +0200

On Sun, Apr 10, 2016 at 10:18:11AM -0400,
 Tim Wicinski <[email-masked]> wrote 

> draft-fujiwara-dnsop-nsec-aggressiveuse

I think it is an useful technique and I think the working group should
adopt it and work on it. I'm willing to review.

I note there is some relationship with
draft-ietf-dnsop-nxdomain-cut. It is "NXDOMAIN cut plus synthesis (if
you have DNSSEC)".

Technically speaking, the weakest point is about NSEC3: most zones
(except the root) are not signed with NSEC, and negative answers
synthesis with NSEC3 seems... difficult (at least for my brain).

---

From: Shane Kerr <[email-masked]>
Date: Tue, 19 Apr 2016 17:13:28 +0200

Stephane,

At 2016-04-15 16:13:44 +0200

> synthesis with NSEC3 seems... difficult (at least for my brain).

I think the draft covers NSEC3, although perhaps not in enough detail?

My basic understanding is that NXDOMAIN synthesis is straightforward
in concept if there is no opt-out (although perhaps tricky in
implementation), and impossible if opt-out is used.

Is there something I am missing?

Also, I'm not sure that it is fair to say "most zones are not signed
with NSEC". I guess most *TLD* are signed with NSEC3 either for zone
size reasons or in a (misguided IMHO) attempt to keep the zone contents
secret. But is this true for domains that are not delegation-only? And
even if it is, are those zones opt-out?

Cheers,

--
Shane

---

From: [email-masked]
Date: Mon, 25 Apr 2016 12:29:43 +0900 (JST)

> From: Bob Harold <[email-masked]>

Thanks.

> would it then allow zone enumeration?

It is true. However, the zone operator controls the range.  If the
zone operator does not want zone enumeration, he will not change the
range.

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 25 Apr 2016 17:41:28 +0000

> We will want several dedicated reviewers on this.

I (obviously) support adoption.
cheese-shop was simply a limited use case of this document to get us some
of the benefits of this *soon*. It was never intended to be a competitor to
this, rather a proof of concept in a zone with known attributes. Getting
nsec-aggressiveuse out the door is the right thing to do...

I'm happy to author, contribute text, review, cheerlead, track issues,
stare pensively into space, whatever is helpful.

> This call for adoption ends 17 April 2016.
Doh. Well, regardless, I still support it.
W

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 Apr 2016 18:33:15 -0400

All

The Call for Adoption has passed and there seems to be strong consensus 
to adopt it. Thanks everyone who has signed up to offer review comments, 
etc.

A new version will be uploaded soon by the authors once they incorporate 
the comments made during the Call for Adoption.

thanks
tim

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Apr 2016 10:11:13 +0200

Late to the party, but FWIW: I also support adoption and am willing to
discuss and review this work.

Some comments:

- Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver
SHOULD support aggressive NSEC usage and enable it by default. This to
me seems inconsistent use of the key words.

- In section 4.3 I suggest to replace the second paragraph with:

   If the full-service resolver's cache contains an NSEC3 matching
   the closest encloser, an NSEC3 covering the next closer name, and
   an NSEC3 covering the source of synthesis, it is possible for the
   full-service resolver to respond with NXDOMAIN immediately.

Also, what exactly defines a full-service resolver? I think we care
about caching and validating only here.

- Section 4.3 suggests to build a separate cache of NSEC and NSEC3
resource records for each signer domain name. This to me seems like an
implementation detail and is not necessarily required. In fact, a zone
may switch from NSEC to NSEC3 and vice versa, so you will need to check
them both if you implement it as a separate cache.

- I don't see why setting the CD bit is an indication that NSEC(3)
aggressive usage should not be used. Could you elaborate on that?

- My body shivers when reading that resolvers MAY use NSEC(3) records in
a NXDOMAIN response without validating them. Luckily the draft already
highly recommends that it should do validation. I would like to make it
even stronger and remove the MAY key word here, and perhaps use the
formal key word SHOULD do validation.

Best regards,
  Matthijs

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 27 Apr 2016 08:29:46 -0700

On 19 April 2016 at 08:13, Shane Kerr <[email-masked]> wrote:

> I feel certain someone has this data.   Ed Lewis, would this be something
that would be possible to pull out of your survey of signed zones?

---

From: Shumon Huque <[email-masked]>
Date: Wed, 27 Apr 2016 11:45:15 -0400

> that would be possible to pull out of your survey of signed zones?

For just the TLDs, "most" is true; I have some data at:

    https://www.huque.com/app/dnsstat/category/tld/dnssec/

In short, 895 or 79.1% of the signed TLDs are using NSEC3.

But that still leaves a non-trivial ~ 21% with NSEC.

-- 
Shumon Huque

---

From: [email-masked]
Date: Thu, 28 Apr 2016 02:57:03 +0900 (JST)

> From: Shumon Huque <[email-masked]>
> In short, 895 or 79.1% of the signed TLDs are using NSEC3

Many TLDs use NSEC3 with OPT-OUT.

# JP uses NSEC3 with OUT-OUT.

hidden) delegations between NSEC3 range.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 28 Apr 2016 10:48:22 +0200

Matthew,

At 2016-04-27 08:29:46 -0700
Matthew Pounsett <[email-masked]> wrote:

> > size reasons or in a (misguided IMHO) attempt to keep the zone
> > contents secret. But is this true for domains that are not
> > delegation-only? And even if it is, are those zones opt-out?
>
> I feel certain someone has this data.   Ed Lewis, would this be
> something  that would be possible to pull out of your survey of
> signed zones?

I don't have a copy of any of the easily-available big TLD
(com/net/org), but I guess it should be relatively easy to look at the
DS records there and see whether NSEC or NSEC3 is used by delegations?

I did ask some developers, and they said that PowerDNSSEC, which is
very popular for hosting in Holland at least, defaults to NSEC. IIRC
the NL domain is the one with the largest portion of DNSSEC signed zones
(although I don't know what portion of the overall DNSSEC picture this
is).

For small to medium zones NSEC seems to make more sense to me... even
for large zones once you have a certain amount of the zone that needs
RRSIG (delegation doesn't require signatures in NSEC3 opt-out, but DS
records still do).

Cheers,

--
Shane

---

From: Marc Groeneweg <[email-masked]>
Date: Thu, 28 Apr 2016 09:24:03 +0000

Matthew (and Shane),

>>>delegation-only? And even if it is, are those zones opt-out?
For .nl it is for zone size reasons.

>I did ask some developers, and they said that PowerDNSSEC, which is very
popular for 
>hosting in Holland at least, defaults to NSEC. IIRC the NL domain is the
one with the 
>largest portion of DNSSEC signed zones (although I don't know what portion 
>of the overall DNSSEC picture this is).
Of the 5.628.017 registered domain names, 2.490.637 are signed (roughly
44%).
We have a delegation only zone with NSEC3.

Regards,
Marc Groeneweg
SIDN

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Apr 2016 13:37:40 +0000

>that would be possible to pull out of your survey of signed zones?

I can answer some of that (why is it those with numbers never have the
whole answer?).

As of March 1st (the last time I did a count):

1241 zones - counting the root plus the top-level names (meaning ARPA/ not
IN-ADDR.ARPA).
1078 signed, 1070 with DS records (the root, and 7 signed TLDs have not
entered a DS)
857 use NSEC3
221 use NSEC

Of those, 925 zones are operated according to agreements for the
class-of-2012 new gTLDs, all of these are signed, etc.,  730 of these are
NSEC3'd, 195 do NSEC (roughly 4:1).  I mention this because it leaves the
others, mostly ccTLDs, with a slightly starker split - 127 NSEC3 to 26
NSEC (5:1).

The 925 zones are delegation only by rule, as well as a smidgen more
(pre-2012 gTLDs whose agreements forbid anything other than delegations,
probably less than 25 more).  ccTLDs are harder to count because they are
not, in general, required to allow their zones to be inspected.  There are
about 300 ccTLDs (roughly), some report internals, others not.

And I know of no DNSSEC software that can mix opt-out and non-opt-out
NSEC3 chains, despite the protocol allowing it, all zones I can see are
"opt-out" if they do NSEC3 at all.

So, for the upper zones, most are NSEC3.  I wouldn't speculate on
motivations for choices, what I do know is what I get when I flat out ask
someone (because DNS doesn't include a "why I'm doing this" field).
Scaling and "checking a policy box" are the reasons.

As far as other zones, it's harder to do this work without the zone files
of the TLDs.  As far as significance, while the upper reaches are like
85+% signed, COM, for instance, has about 1/2% signed which is also 1/2
million delegations.  (Small percent, large magnitude.)

In making "policy" decisions like when to assume some statement holds, it
would be good to measure all of this, wouldn't it? ;)

Not sure if that answers the question fully.  Hope it helps.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 28 Apr 2016 22:28:45 +0200

Matthijs,

At 2016-04-26 10:11:13 +0200

> me seems inconsistent use of the key words.

I think it's that:

  4.1 applies to any use of aggressive NSEC/NSEC3 (MAY)
  4.2 applies to NSEC (SHOULD)
  4.3 applies to NSEC3 (MAY)

I agree it looks a bit confusing. I think the main issue is whether
NSEC should be recommended. I kind of like it, because of the overall
benefits to the network. Without the SHOULD, people building software
from checklists will likely drop this optimization.

Perhaps 4.2 could be changed to something like:

    "If a full-service resolver implementation supports aggressive
    negative caching, then it SHOULD support aggressive use of NSEC and
    enable it by default. It SHOULD provide a configuration knob to
    disable aggressive use of NSEC."

?

> about caching and validating only here.

"Full-service resolver" is in our brand-new terminology RFC 7719:

   Full-service resolver:  Section 6.1.3.1 of [RFC1123] defines this
      term to mean a resolver that acts in recursive mode with a cache
      (and meets other requirements).

> them both if you implement it as a separate cache.

Perhaps the words "need to" can be replaced with "may" to make it clear
that this is not a requirement, but one possible approach?

Cheers,

--
Shane

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 28 Apr 2016 15:05:05 -0700

> Not sure if that answers the question fully.  Hope it helps.

It helps, for sure.  So if I understand you correctly, at the TLD level
it's 4:1 in favour of NSEC3, and all of those are opt-out.
I imagine that will change as the number of DS records rise, but it gives
us an idea of the scale of the issue.

So back to Shane's question which I was responding to ...
We can't say that most zones are NSEC or NSEC3, but we can say there are an
awful lot of TLDs that are NSEC3 opt-out.

If someone can get me a relatively current, and relatively complete, set of
TLD zones, I could volunteer to check the next level down.  I don't think I
have time to go through the process of signing and faxing all those zone
file access agreements though.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 29 Apr 2016 10:09:30 +0200

Shane,

> from checklists will likely drop this optimization.

Reading over RFC 2119 I think MAY is more applicable. The quotes from
that RFC that convince me so:

   One vendor may choose to include the item because a particular
   marketplace requires it or because the vendor feels that *it
   enhances the product* while another vendor may omit the same item.

and

   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, *though perhaps with reduced functionality.*

Also I don't think the key words need to be different for NSEC and NSEC3.

> that this is not a requirement, but one possible approach?

That works, but my argument is that one should be careful with the
assumption that a zone is either uses NSEC or NSEC3, while that may be
true at one point in time, a zone may change its DNSSEC policy and
switch to the other.

>> aggressive usage should not be used. Could you elaborate on that?

I am still hoping that someone could response to this :)

Thanks.

Best regards,
  Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Fri, 29 Apr 2016 10:12:43 -0700

At Fri, 29 Apr 2016 10:09:30 +0200,

> I am still hoping that someone could response to this :)

Specifically where in draft-fujiwara-dnsop-nsec-aggressiveuse-03 are
you referring to?

--
JINMEI, Tatuya

---

From: Edward Lewis <[email-masked]>
Date: Fri, 29 Apr 2016 19:08:54 +0000

On 4/28/16, 18:05, "DNSOP on behalf of Matthew Pounsett"
<[email-masked] on behalf of [email-masked]> wrote:

> It helps, for sure.  So if I understand you correctly, at the TLD level it's
> 4:1 in favour of NSEC3, and all of those are opt-out.
> I imagine that will change as the number of DS records rise, but it gives us
> an idea of the scale of the issue.

I do know of one operator whose told me that the are considering swapping
NSEC for NSEC3 as the zone size is putting pressure on the infrastructure.

I see other trends that say operator behavior is unpredictable.  Operators
are still debuting zones with RSA-SHA1, for instance, despite educational
efforts to go to something newer.  So, while there's a little bit of pent up
energy to go from NSEC3 to NSEC, there's no telling whether future debuts
will feature one or the other.

> awful lot of TLDs that are NSEC3 opt-out.

Yep - the question is, if we don't know, can we just go forward with the
uncertainty?

> have time to go through the process of signing and faxing all those zone file
> access agreements though.

If I had time, I've done studies along the lines you are thinking of.  Last
year I studied the selections of DNSSEC security algorithms and lengths but
didn't include NSEC in the work then.  Between the time I did the work and
got around to talking about it (at CENTR Jamboree 2015) a higher priority
work item overcame events.  The data I have access to is pretty much
not-the-ccTLDs.  File this under best laid plans...I do need to fix my set
up last year after changing hardware.