On Mon, Feb 22, 2010 at 11:59 AM, Evan Hunt <[email protected]> wrote: >> 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." > > Mark was responding to an assertion to the contrary ("one is NOT better > than the other") by making a boundary-condition quibble. I'm not sure > whether he was arguing that the quibble should be noted in the draft > or merely being pedantic, so I won't speak for him, but I personally > think precision is a worthwhile goal here. > > Note that RFC 5155 takes the time to put the issue to rest not once but > twice: > > Note that with the hash algorithm specified in this document, > SHA-1, such collisions are highly unlikely. > > Hash collisions between QNAME and the owner name of an NSEC3 RR > may occur. When they do, it will be impossible to prove the > non- existence of the colliding QNAME. However, with SHA-1, > this is highly unlikely (on the order of 1 in 2^160). Note that > DNSSEC already relies on the presumption that a cryptographic > hash function is second pre-image resistant, since these hash > functions are used for generating and validating signatures and > DS RRs. > > ... so I don't understand why 4641bis should not do so even once. (But > this conversation has already taken more time than the probability of a > random collision really merits, so whatever.)
Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls into the category of "basic assumptions" -Ekr _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
