Subject: More on NSEC2 label size and DoS

From: [email-masked]
Date: Wed, 26 May 2004 10:11:11 +0200 (CEST)

Hi,

I still see a technical limit with NSEC2:

1) multiple hashed labels.

I assume that every label needs to be hashed individually (Ben ?). Due to
the SHA-1 digest size in base32, (32 characters), plus 1 byte label
length+type, and a maximum owner name length of 255 bytes, there is a
maximum of 7 hashed labels, i.e., there are issues for names like:

1.1.1.1.1.2.2.2.2.3.3.1.2.3.4.in-addr.arpa. and
5.4.1.4.1.1.0.1.6.3.1.e164.arpa.

2) DoS issue with multiple labels.

Since a hash(label) needs to be performed by the server to look up
(internally) the proper NSEC for proof, the effort for creating a response
would be higher then the effort for sending a query, compared to NSEC or
non-DNS.

Roy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Wed, 26 May 2004 10:20:37 +0200 (CEST)

btw, if hashes are per owner name instead of per label, then other size
issues are at hand, since for every intermediate label level (empty non
terminal) a new NSEC+SIG (or EXIST) needs to be created.

That hurts in zones under ip6.arpa and e164.arpa.

Roy

---

From: [email-masked]
Date: Wed, 26 May 2004 12:22:10 +0200 (CEST)

On Wed, 26 May 2004, Jim Reid wrote:

> >>>>> "roy" == roy  <[email-masked]> writes:
>
>     roy> btw, if hashes are per owner name instead of per label, then
>     roy> other size issues are at hand, since for every intermediate
>     roy> label level (empty non terminal) a new NSEC+SIG (or EXIST)
>     roy> needs to be created.
>
>     roy> That hurts in zones under ip6.arpa and e164.arpa.
>
> Something similar to NSEC2 would be pointless for e164.arpa because
> the name space is regular and well-known: eg all North American E.164
> numbers are exactly 10 digits long after the +1. Enumeration of this
> name space using DNS lookups is a no-brainer irrespective of how or if
> the zones get signed.

True, but irrelevant. If NSEC2 is adopted, deprecating NSEC, it does not
discriminate between reverse and forward zones. If ip6.arpa is signed, it
is signed with NSEC2. No choice, no way out.

Roy

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 May 2004 11:13:38 +0100

---

From: [email-masked]
Date: Wed, 26 May 2004 18:59:39 +0200 (CEST)

On Wed, 26 May 2004, Ben Laurie wrote:

> [email-masked] wrote:
> This is true. I have not calculated how much it hurts. It is related to
> the sparseness of the domains. Are there figures for those?
>
> A back of the envelope calculation I did on the plane says that for e164
> in dense domains, the hit is 10-100% extra. For sparse domains it can be
> much higher, but presumably sparse domains are small.

Okay, the problem is not e164 but ip6.arpa:

9.1.1.0.6.0.1.0.7.8.0.0.2.9.1.0.a.0.0.8.1.0.0.0.0.1.6.0.1.0.0.2.ip6.arpa.

Remember, at _each_ intermediate label level including empty non-terminals
(in the above example there are 35 labels) a NSEC (or EXIST) is needed for
every occuring value at that label.

Roy

---

From: [email-masked]
Date: Wed, 26 May 2004 19:33:57 +0200 (CEST)

On Wed, 26 May 2004, Ben Laurie wrote:

> My intention (I cannot speak for the WG, of course) was to make it
> possible to choose NSEC or NSEC2, since if you don't mind zonewalking,
> you shouldn't have to incur the overhead of NSEC2.

ack

---

From: [email-masked] (Geoffrey Sisson)
Date: Thu, 27 May 2004 14:50:20 +0100 (BST)

> every occuring value at that label.

This is a good argument for NSEC2 as an _alternative_ to NSEC rather
than as a replacement.  It's probably undesirable to secure zones in
{in-addr,ip6,e164}.arpa using NSEC2 RRs, especially as the namespace of
domains in these zones is dramatically smaller.

Regards

Geoff