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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
