> 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.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop