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

From: Matthijs Mekking <[email-masked]>
Date: Sun, 1 May 2016 19:20:33 +0200

On 29-04-16 19:12, 神明達哉 wrote:
> At Fri, 29 Apr 2016 10:09:30 +0200,
> Matthijs Mekking <[email-masked]> wrote:
> 
>>>> - 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?
>>
>> I am still hoping that someone could response to this :)
> 
> Specifically where in draft-fujiwara-dnsop-nsec-aggressiveuse-03 are
> you referring to?

Section 5.1. Specifically I think that the CD bit signals to disable
signature validation in a security-aware name server (but does not
prevent it from happening anyways), but that does not disable answering
already validated data from its cache.

Best regards,
  Matthijs

> --
> JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 2 May 2016 10:32:54 -0700

At Sun, 1 May 2016 19:20:33 +0200,

> already validated data from its cache.

I didn't (and still don't) interpret that section as a query with the
CD bit shouldn't be answered with a cached NSEC applying
nsec-aggressiveuse.  To me it seems to be just silent about that
point.  I guess it simply assumes a particular validator behavior that
skips DNSSEC validation on queries with the CD bit (and the resulting
NSEC can't be used for subsequent nsec-aggressiveuse as it's not
validated) and considers that can be exploited by an attacker.

But your actual point is probably: if the validating recursive server
performs DNSSEC validation for an answer triggered by a query with the
CD bit (but returns the answer whether or not it validates; that's the
real normative part of the protocol with a SHOULD), and if the
validating recursive server uses the validated (and cached) NSEC for
subsequent nsec-aggressiveuse, sending queries with the CD bit
wouldn't be an effective attack vector as the section suggests.

In that sense, I agree with you and I also think what's (seemingly)
stated in this section does not make much sense.

Personally, though, I have an even more fundamental question on this
section: to me, the claimed benefit of this approach as a defence
against "random subdomain attacks" is very weak, and all related
discussions in that context just makes the document unnecessarily
complicated.  If we simply consider this technique as a
possibly-nice-to-have optimization, the CD bit discussion will become
simply unnecessary.  So I'd suggest re-purposing the draft and just
remove this section (or just mentions the validator should perform
DNSSEC validation even if it's triggered by a query with the CD bit to
make this technique more effective).

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Fri, 06 May 2016 00:49:33 +0900 (JST)

Thanks, Jinmei.

> From: 神明達哉 <[email-masked]>
> - 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.

I would like to remain all benefits in the abstract.
I will rewrite the sentense as the following.

  With this proposal, it is expected that
  performance improvement for recursive servers,
  reducing garbage traffic to authoritative servers
  and possible countermeasure of random subdomain attacks.

> - 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.

I will move texts from Section 1 Introduction to Section 3
and add three benefits.

> - 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.

agree.

> - 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.

The sentence shows current specifications (Section 4.5 of RFC 4035 and
previous RFCs).

>    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.

The second sentence shows the aggressive use of ... changed the first
paragraph.

> - 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.

I agree. I added "[[ This section may be removed. ]]" and removed
the proposal of ignoring CD bit.

> - 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.

These parts may be useless.

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

---

From: [email-masked]
Date: Fri, 06 May 2016 01:44:19 +0900 (JST)

> From: Matthijs Mekking <[email-masked]>
> 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.

I agree.

I used Shane's text.

> - 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.

Thanks. "closest encloser" and "next closer name" is defined in RFC 5155.
I cannot find the definition of "source of synthesis".

I rewrote as 
  an NSEC3 covering wildcards of the closest encloser
  [[ the part may be replaced as: an NSEC3 covering the source of synthesis ]],

# may be rewritten by co-author.

> - 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 agree.

removed the sentence.

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

Section 3.2.2 of RFC 4035 states that:

   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question.

aggressive negative caching may be "local authentication policy".

> - 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.

Yes. I agree.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 May 2016 10:02:08 -0700

> I would like to remain all benefits in the abstract.

I'm not sure if you agreed to my higher-level comment on the "benefit"
as a DoS defense being too weak.  According to the response to, e.g.,
the CD bit section, it seems you agreed, but in that case this doesn't
make sense; at least that part of the "benefit" should be removed (not
only from the abstract but from the draft in general).

>   and possible countermeasure of random subdomain attacks.

So, at least I'm opposed to this text.  To repeat myself, my
higher-level general suggestion is to re-purpose this draft as a
possible performance (and many network traffic) optimization,
completely dropping the claim as a DoS defense, and revise overall
text according to it.  (You might disagree, but in that case my
personal response to the adoption call will be "no").

> The sentence shows current specifications (Section 4.5 of RFC 4035 and

Ah, so you actually referred to bullet #1 of RFC 4035 Section 4.5.  I
see that, but in that case I'd suggest you refer to the RFC explicitly
here, and clarify that this is a "deduced" wildcard.

> The second sentence shows the aggressive use of ... changed the first

I still don't get it here.  Can you perhaps show a specific example of
"send a positive response immediately when the name in question
matches a NSEC/NSEC3 RRs in the negative cache."?  Especially about
how "a positive response" is derived from negative cache information?

--
JINMEI, Tatuya

---

From: Matthijs Mekking <[email-masked]>
Date: Sat, 7 May 2016 12:11:35 +0200

> I cannot find the definition of "source of synthesis".

It's here: https://tools.ietf.org/html/rfc4592#section-3.3.1

> aggressive negative caching may be "local authentication policy".

Still, if the records are rejected by the recursive name server it would
not end up in the cache. So aggressive NSEC usage is not even possible
in that case. I think it is perfectly acceptable for a resolver to
behave like this when an incoming query with CD bit is received:

1. Check for data in the cache
2. Check for non-existence in the cache / NSEC aggressive use
3. Check the BAD cache
4. Query upstream

So again, I think NSEC aggressive usage can still be used if the CD bit
is set.

Best regards,
  Matthijs

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

---

From: [email-masked]
Date: Mon, 09 May 2016 19:46:01 +0900 (JST)

>> I would like to remain all benefits in the abstract.

I discussed with co-author.

I will rewrite "performance improvement for recursive servers" as a
purpose of the draft, and "possible countermeasure of some attacks" as
side effect.

> here, and clarify that this is a "deduced" wildcard.

OK, I will refer the section.

> how "a positive response" is derived from negative cache information?

I will update the part to be expressed well.

If nonexistence of a domain name is proved and there is a matching
wildcard for the domain name, then the domain name matches the wildcard.

the current draft may be lack of a description.

Regards,

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 May 2016 09:55:05 -0700

> wildcard for the domain name, then the domain name matches the wildcard.

Ah, okay, now I see it.  I think there's some logical gap here, which
I believe could be improved through some wording change:

- the last paragraph of RFC 4035 Section 4.5 talks about aggressive
  use of a cached deduced wildcard (as well as aggressive use of
  NSEC) but rather recommends not to rely on it.
- just like the case for the aggressive use of NSEC discussed in this
  draft, we could revisit this recommendation.  as long as the
  recursive server knows a name would not exist without the wildcard
  match, it could answer a query for that name using the cached
  deduced wildcard, and it may be justified for performance and other
  benefits.  (Note that, so far, this is orthogonal to "when
  aggressive use (of NSEC) is enabled").
- *Furthermore* when aggressive use of NSEC is enabled, the aggressive
  use of cached deduced wildcard will be more effective as the
  aggressive NSEC use helps prove more names wouldn't exist without
  the wildcard through fewer external queries.

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Thu, 12 May 2016 17:26:44 +0900 (JST)

> It's here: https://tools.ietf.org/html/rfc4592#section-3.3.1

Thanks.

I added these key words in terminology section and I will add them to rfc7719bis.

I rewrote pseudo code easier.

---

From: [email-masked]
Date: Thu, 12 May 2016 18:57:36 +0900 (JST)

Thanks.

I used these texts.