> 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 -- [email protected]
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
