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: Alex Bligh <[email-masked]>
Date: Tue, 21 Feb 2006 19:11:14 +0000

> result in a significant denial-of-service on the resolver.

Hmmm... Off the wall idea for today: Suppose that rather than using
just some local resolver config knob, you looked at the parent
zones number of hash iterations, and did not allow a number of
hash iterations which exceeded both some function of that AND the
config knob.

Then, when as and when the root goes NSEC3, increasing computation
power could be reflected in an increase in the root hash iterations,
TLD iterations, etc. etc.

You'd still have your local config knob for delegations which
went (say) NSEC3->NSEC->NSEC3.

Alex

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Feb 2006 14:39:34 -0800

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

Specifying a maximum will help interoperability (zone operators that
pick a higher iteration factor than the default deployed max will run
into issues).  However, it also locks you into a time frame where the
number either has too be too small for the future (deployment in the
future with faster processors may want more iterations) or too large
for the present (trying to pick a large enough number for the future
will invariably mean that you'll still allow for more of the DoS
attack today that you're trying to prevent).

-- 
Wes Hardaker
Sparta, Inc.

---

From: Geoffrey Sisson <[email-masked]>
Date: Wed, 22 Feb 2006 23:43:39 +0000

> 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: Wes Hardaker <[email-masked]>
Date: Thu, 23 Feb 2006 13:12:59 -0800

>>>>> On Wed, 22 Feb 2006 23:43:39 +0000, Geoffrey Sisson <[email-masked]> said:

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

Or...  wait for it....  wait for it...

A new RRTYPE at the zone (thus should always exist for nsec3 enabled
zones) containing the number of iterations (or a range) that the zone
uses for it's nsec3 records.  Implementations could choose to query
for that record if the number advertised in a return nsec3 record was
greater than what it wanted to calculate without verifying it has to.

I'm about 90% kidding, but it would help.

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

True.

Another related attack is actually not for people forging NSEC3
records and returning them to an attacker, but is actually much worse:
Consider a registered zone with huge nsec3 iterations in it.  Then
consider sending mail from that zone to any mail server that performs
dns lookups for spam checking or other filtering reasons.  Now imagine
sending 10000 messages or more.

-- 
Wes Hardaker
Sparta, Inc.