[dnssec-deployment] aug2004 CAM of interest?
Mike.StJohns at nominum.com
Thu Aug 19 12:26:29 EDT 2004
>Speaking as someone who has trouble decoding plain text, I don't
>understand all of the fuss about finding collisions in a hash
>function like SHA-1. Surely there are more than 2^160 things in the
>universe and if you try to map all of this into a 2^160 bin
>receptacle you're going to have a collision.
>'Course, if you restrict the universe to just DNS RR's that have the
>same name, type, and class, the chance you'll get a collision
>*should* be much less. Even if a good hash function is demonstrated
>to produce a collision, the applicability of that demonstration to
>DNSSEC data eludes me.
>E.g., SHA-1(a zebra) probably equals the SHA-1(continent of Asia).
>But so what? You're not going to sneak the Asia into the Bronx zoo
>to steal a zebra.
>Perhaps I need more of an education...
Assume a toBeSigned value (e.g. a DNSSEC RRSet plus the RRSig template) of
D, the actual value of the RRSig signature is SIGN(Hash(D),K) where K is
the private key. If you can find a D' where Hash(D) == Hash(D') then you
can substitute D' for D in the data you send in response to a DNSSEC aware
query and have it be treated as valid by the receiver.
The problem with this scenario is that D and D' can't be just random
strings of data - they have a specific DNS format. So not only do you have
to find data that collides, but it has to look like a valid RRSet AND has
to match the data of the RRSig also covered under the hash value.
(Its not just a same name/type/class collision - the data to be hashed can
point at other names and other types and probably will. The more
interesting protection is that the value of key tag and signer's name can't
be different because they have to point at the DNSKEY record).
More information about the Dnssec-deployment