Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Evan Hunt <[e-mail]>]

> 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-mail]
Internet Systems Consortium, Inc.