Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-02.txt

From: 神明達哉 <[email-masked]>
Date: Mon, 9 May 2016 11:01:30 -0700

At Mon, 25 Apr 2016 21:39:32 +0200,
Stephane Bortzmeyer <[email-masked]> wrote:

>  Stephane Bortzmeyer <[email-masked]> wrote
>  a message of 17 lines which said:
>
> > >         Title           : NXDOMAIN really means there is nothing underneath
> > >         Authors         : Stephane Bortzmeyer
> > >                           Shumon Huque
> > >     Filename        : draft-ietf-dnsop-nxdomain-cut-02.txt
> >
> > We believe it implements all the changes that were on the slides at
> > the Buenos Aires meeting and that it addresses all the remarks we got
> > (and even a few more).
>
> It seems everyone was tired after Buenos-Aires. Come on, you certainly
> have something to say, positive or negative, about this draft.

I've just read the very latest version (03) of the draft.  It looks
good to me.  I'd even support it if there were now a WG last call.

I've noticed a couple of minor points in this iteration of read.  You
may or may not want to address it in a subsequent version:

- Section 2

   If the NXDOMAIN response due to a cached non-existence is from a
   DNSSEC signed zone, then it will have accompanying NSEC or NSEC3
   records that authenticate the non-existence of the name.  [...]

  The behavior described in this section is one form of
  [I-D.fujiwara-dnsop-nsec-aggressiveuse].  You might note this point,
  referring to the I-D (and maybe also referring to Appendix B).

- Section 3

   "NXDOMAIN cut" may also help mitigate certain types of random QNAME
   attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a
   fixed suffix which does not exist.

  This is true, but I suspect it would be pretty easy for this type of
  attacker to circumvent the effect if and when the nxdomain-cut
  behavior is more widely deployed.  An attacker for the '.wf' zone
  would simply send random junk query <random>.wf instead of
  <random>.dafa888.wf.  So I think the mitigation effect in this sense
  is quite limited.

--
JINMEI, Tatuya

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 May 2016 18:45:49 -0400

>   referring to the I-D (and maybe also referring to Appendix B).

We did consider adding a reference to it earlier, but decided to wait to
see if it would be adopted by the working group. Perhaps it's time now.

>   <random>.dafa888.wf.  So I think the mitigation effect in this sense

Yes, that's why we were careful to say that "certain types" of attacks
"may" be mitigated. Implicit in that sentence was the recognition that
other patterns of random subdomain attacks would not be stopped and
that attackers could adapt. Do you have a specific suggestion regarding
the text? Did you want the limitation stated more explicitly? Or do you
think this topic isn't worth mentioning? Or ...

-- 
Shumon Huque

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 May 2016 15:04:56 +0200

On Mon, May 09, 2016 at 11:01:30AM -0700,
 神明達哉 <[email-masked]> wrote 
 a message of 49 lines which said:

>   This is true, but I suspect it would be pretty easy for this type
>   of attacker to circumvent the effect if and when the nxdomain-cut
>   <random>.dafa888.wf.  So I think the mitigation effect in this
>   sense is quite limited.

Speaking of that, I have a philosophical question. Attackers in the
real world (not in labs or in security conferences, where researchers
try to impress their peers with clever hacks) are often
unsophisticated. All the random qnames attacks I've seen (last one was
reported on the Unbound users mailing list a few days ago under the
title "Ratelimit misbehavior") use a 3-labels name. This is indeed
stupid: even without "NXDOMAIN cut", it makes identification and
classification of the offending packets very simple (via Netfilter
with u32, for instance). Why do they continue to do so?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 May 2016 09:18:05 -0400

One observation to make about this is that it's not that they are stupid,
but that they don't care about being clever.   They just care that it
works.   So probably somebody reasonably smart did the three-label attack
because the DNS geek in them was trying to be neat, even as the attack geek
in them was trying to be messy.

Make this stop working, and they will adjust quickly.

On Tue, May 10, 2016 at 9:04 AM, Stephane Bortzmeyer <[email-masked]>
wrote:

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 May 2016 15:27:41 +0200

On Tue, May 10, 2016 at 09:18:05AM -0400,
 Ted Lemon <[email-masked]> wrote 

> Make this stop working, and they will adjust quickly.

Filtering on the QNAME works fine (quite easy with such long suffixes)
and they did not adjust.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 10 May 2016 08:44:20 -0700

At Mon, 9 May 2016 18:45:49 -0400,

> think this topic isn't worth mentioning? Or ...

I don't have a particular/strong suggestion.  I just provided some
observation I happened to have from my latest read of the document.
If we all think this particular point is not that important, I might
consider removing it if only to make it shorter (and therefore more
friendly for readers).  But if you think it still has some value, I
have no problem with keeping it in its current form.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 10 May 2016 08:54:59 -0700

At Tue, 10 May 2016 15:04:56 +0200,
Stephane Bortzmeyer <[email-masked]> wrote:

> unsophisticated. [...] Why do they
> continue to do so?

I don't know:-)  In any case, my comment on this was not to request a
particular change to the draft.  But I believe one with a decent
knowledge on DNS won't have to be particularly "clever" to have the
same question, you might want to add more discussion to answer (or at
least respond to) that question if we keep this topic in the draft.
It's up to you.

--
jinmei

---

From: Steve Crocker <[email-masked]>
Date: Tue, 10 May 2016 11:56:23 -0400

Ok, thanks.

Steve