Subject: NSEC3 Issue 9: Potential DoS on Resolvers

From: Geoffrey Sisson <[email-masked]>
Date: Tue, 21 Feb 2006 18:26:36 GMT

NSEC3 Issue 9: Potential DoS on Resolvers

Issue:

A potential DoS condition exists in which the operator of a malicious
server could select an impractically high number of iterations for the
NSEC3 RRs in an signed zone.  The NSEC3 RDATA format permits values as
high as 2 ^ 23, or 8,388,608 (N.B. this is a change in -04; in -03 it
was 2 ^ 24).  Consequently, when a resolver receives multiple queries
for names (existent or non-existent) in this zone, the resolver must
perform the same number of hash iterations for each query.  This could
result in a significant denial-of-service on the resolver.

Discussion:

One solution would be to permit resolvers to set an upper limit for the
number of iterations that would be permitted in an NSEC3 RR, and to
treat NSEC3 RRs with values exceeding this as insecure or bogus.  This
could be accomplished at the implementation level alone, or it could be
governed by a recommendation or standard.

One subsidiary issue is that any limit may have to change over time in
response to increases in computational speed: a limit which may
initially reflect an unjustifiably high number of iterations may later
be considered cryptographically weak.

Proposed Resolution:

We agree that it is desirable for resolvers to set an upper limit.

We propose to submit the following two questions for consideration by
the IETF Security Area Directorate:

1.  Should an upper limit be specified in the standard?

2.  If so, should the upper limit be specified in a separate document
    so that the it may be updated without having to re-publish the
    entire standard.

--
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: Geoffrey Sisson <[email-masked]>
Date: Wed, 22 Feb 2006 23:43:39 +0000

Wes Hardaker <[email-masked]> wrote on 22/02/2006 22:39:34:

> >>>>> On Tue, 21 Feb 2006 18:26:36 GMT, Geoffrey Sisson 
> <[email-masked]> said:
> 
> Geoffrey> 1.  Should an upper limit be specified in the standard?
> 
> Geoffrey> 2.  If so, should the upper limit be specified in a separate 
document
> Geoffrey> so that the it may be updated without having to re-publish
> Geoffrey> the entire standard.
> 
> It would make sense (to me) not to specify a particular number as
> though-shall, but rather as a "at the time of this writing a decent
> default to choose"...  Ideally, resolvers should be configurable with
> this upper limit and it should be changeable.

Without an authoritative reference, increases to max iteration may be
nearly impossible to coordinate.  Even with an authoritative reference
we'll have a "root.hints"-type issue where a long tail of resolvers will
be slow to update.

One thought, though: perhaps max iterations could be registered as
an IANA protocol parameter rather than in a formal document.

Another consideration: there will presumably have to be distinct max
iterations values for each NSEC3 hash function in use.

Geoff

---

From: Alex Bligh <[email-masked]>
Date: Sat, 25 Feb 2006 19:31:16 +0000

--On 24 February 2006 18:11 +0000 Geoffrey Sisson <[email-masked]> 
wrote:

> The problem with the 10% non-kidding part is that a malicious/ignorant
> zone operator could put the value in this RR arbitrarily high, too.

That was why I was (again 90% kidding) suggesting it got inherited
from its parent.

Alex