In message <222b7737-d294-4ef1-9f14-de4ca4c70...@dnss.ec>, Roy Arends writes: > On Feb 22, 2010, at 6:41 PM, Mark Andrews wrote: > > >=20 > >> The real problem is that a SHA1 hash collision would render all = > signatures wi > >> th RSASHA1 vulnerable. Haven't heard you about that.=20 > >=20 > > Hogwash. A collision is nothing more than a collision. See above. > > So, a collision (that is nothing more than a collision) is a problem for = > NSEC3, but not for RSASHA1?
What matters is how the collision came about not that there is a collision. Just because something is extremely unlikely doesn't mean that it won't happen or that the process is broken. SHA1 being broken implies that collisions will happen more often. Seeing a collision doesn't imply that SHA1 is broken. > > 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 agree, approximately, a probability of 1 in 2^135. > > >> 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. > >>=20 > >>> (resign > >>> with a new salt, and also keep that 2-second update guarantee? - I = > would > >>> suggest some weasel words in agreements). > >>=20 > >> Nah, we love collisions, it makes it all so more efficient. > >>=20 > >> Besides, I think=20 > >> the probability of finding a bug in authoritative server software is = > way high > >> er than a hash-collision. > >=20 > > Indeed. But you would expect us to fix the bug once it was found. :-) > > I used to. Not anymore. > > See = > https://www.isc.org/community/blog/201002/surprise-bugs-and-release-schedu= > les > > Roy= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
