Re: NSEC3 Issue 10: Potential DoS on Servers,

[Ben Laurie <[e-mail]>]

David A. Wheeler wrote:
> Earlier an "NSEC3 issue 10" was noted, saying:
>> Significantly more work is required for a name server to
>> respond to queries which require negative proofs using NSEC3
>> than is required for a client to compose and send them.
> 
> I don't understand this as an issue, and I'm concerned that I may be
> misunderstanding NSEC3.  It seems to me that the whole point
> of the NSEC3 design is that all the hashes and signatures can
> be precomputed, offline.  You don't want the signing key to BE on-line,
> and you cannot assert that hash ranges don't exist until you've
> computed ALL the valid hash values anyway. And the hash already includes
> the salt, iterations, etc.  So I'd expect the entire chain of hash
> calculations and signing to be done off-line, where DoS is irrelevant.
> 
> Thus, when a client sends a request, the server should be able to
> trivially determine the non-match, find the relevant NSEC3 key
> (a trivial binary search would be fine), and send the appropriate canned response.
> The computation in view is very trivial; I wouldn't expect any complex computations
> to be done for an NSEC3 response by a sensible name server (at run time).
> 
> Do I misunderstand things?  If so, please enlighten me!

The problem is that the server has to calculate iterated hashes to find
the right NSEC3 records.

> 
> 
> --- David A. Wheeler 
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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