In message <[email protected]>, Roy Arends writes: > On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote: > > > On 02/22/2010 04:53 AM, Roy Arends wrote: > >> On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote: > >> > >>> NSEC3 > >>> has a non zero false positive rate due to the fact that the names > >>> are hashed. > >> > >> Are you going on again about the possibility of hash collisions is SHA-1? > > > > Yes. +1 for Marks point. > > > > The deployment of NSEC3-signed toplevel domains is a giant hash > > collision test of typo dictionaries. > > Not really, most (will) use Opt-Out. > > > What does the registry do when > > someone registers a new domain name that has a hash-collision > > We'll claim that sha-1 is broken, write a paper on it and have our 15 minutes > of fame. Meanwhile...
Actually all you can claim is that you found a collision. It doesn't mean that sha-1 is broken. For sha-1 to be broken you need to be able to *manufacture* a collision or significantly reduce the cost of finding a collision. > In the real world, if someone registers the name 759345ihkjgrj345837458fjfgiu > sifghgvtsrhf8hfvihi.co.uk and its hash collides with example.co.uk (lets skip > the probability factor), than its just gotten a bit more efficient. One hash > matching 2 names, i.e. we can now deny two names for the price of one. As long as the collision falls into the correct set. For delegation only NSEC3 zones (single label) have three sets of NSEC3 hashes for owner names in the zone. The apex NSEC3, those that appear in the zone (secure delegations) and those that should not appear in the zone (opted out name). You don't want a delegation which collides with one of the other sets. > The real problem is that a SHA1 hash collision would render all signatures wi > th RSASHA1 vulnerable. Haven't heard you about that. Hogwash. A collision is nothing more than a collision. See above. There are roughly 63^37/32^32 (2575141059497371630) possible LDH names for every possible NSEC3 owner in a zones containing only single labels. The probability of any single query will collide is vanishing small. NSEC3 works because the number of hashed names in a zone is very very very much smaller than the size of the hash space and we are willing to accept a SERVFAIL on a collision for a name that is not in the zone but is in the namespace. For names that are in the zone we can ensure that there isn't a collision that matters. For a zone with 30 million names the false positive rate is roughly 1 in 32^32/(3*10^7) (1/48716721244363430606789494423876100655197) queries. Around 40 9's. > I suggest that if you and Andrews want to have this claim rfc4641bis, you sho > uld not discriminate on NSEC3, but on everything that uses SHA1. > > > (resign > > with a new salt, and also keep that 2-second update guarantee? - I would > > suggest some weasel words in agreements). > > Nah, we love collisions, it makes it all so more efficient. > > Besides, I think > the probability of finding a bug in authoritative server software is way high > er than a hash-collision. Indeed. But you would expect us to fix the bug once it was found. :-) > > But I agree more pertinent to choice is the increased CPU demand and > > larger packets when using NSEC3. And opt-out, obfuscation desiderata. > > All FUD. > > Roy > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
