Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Roy Arends <[e-mail]>]

On Feb 22, 2010, at 12:23 PM, Evan Hunt wrote:

>> This is absurd. If we're going to do this, I'd like the security
>> considerations to reflect all of the non-zero probabilities of errors
>> occuring (those that have a higher probability).
> 
> My point is not to say that hash collisions are a problem or that NSEC3 is
> a poor choice.  My point is that it's bad form to make mathematically false
> statements--even if they're *almost completely* true--and especially so
> when you get anywhere near cryptographers.
> 
> "NSEC3 is exactly as good as NSEC" is a mathematical statement.  It's very,
> very close to true, but in math that still makes it false.  "NSEC3 is as
> good as NSEC except under conditions so fantastically improbable that it's
> safe to ignore them" is a few more words, but has the benefit of actually
> being *true*, and I think that's what the draft should say.

I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC".

I've seen the opposite by Mark Andrews:

  "Actually NSEC is technically better at proving non-existance."

Which he bases on the possibility of hash-collisions without noting the 'fantastical improbability' of hash-collisions. If one considers hash-collisions probable enough to add it to a security section, it needs a discussion of the _impact_ of a hash-collision on proving (non-)existence (which I've demonstrated is negligible), but also discuss it in the presence of RSASHA1 signature algorithms. And I wasn't kidding in my last mail: If we are going to write that up in a security section, I think we need to consider more probable attack scenarios as well, don't you think? Otherwise, you'd have a section that is "very, very close to true, but in math that still makes it false.", especially so when you get anywhere near security-folk.

Roy