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] (Geoffrey Sisson)
Date: Thu, 27 May 2004 14:50:20 +0100 (BST)

[email-masked] writes:

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

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