Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03

[Eric Rescorla <ekr at networkresonance.com>]

Robert Sparks <rjsparks at estacado.net> writes:

> So, I read this to say the proposed recommendation of CRC32 as
> specified in rfc3309 is ok to go forward with.

I think this is fine.


> Based on the discussion, I think I will also point out that MD5 can
> be used (and has been used in the past),
> that its use would rely only on its collision properties, not any
> cryptographic properties, and point out that it
> is much slower than the alternative above.
>
> Any objection?

No to the choice of CRC32, but yes to the language you suggest
above. Collision-resistance is a technical term in cryptography,
the text above is quite confusing. 

Informally, the property you want is that two hashes of the
input values have a 2^(-b) chance of having the same hash
value. Formalizing this turns out to be a really knotty problem
especially if you assume (as is true in this case) that the
input strings are non-uniform. (universal hashing is one 
way around this problem).

Anyway, I think the correct language ought to be something
like this:

   A common way to create the second part of the branch parameter
   value when forking a request is to compute a hash over the
   concatenation of the Request-URI, any Route header field values
   used during processing the request and any other values used by the
   location service logic while processing this request. The hash
   should be chosen so that there is a low probability that two
   distinct sets of these parameters will collide. Because the maximum
   number of messages which need to be compared is 70 [is this right],
   the chance of a collision is low even with a relatively small hash
   value, such as 32 bits. CRC-32 [REF] is a specific acceptable
   function, as is MD5 [REF].  Note that MD5 is being chosen purely
   for non-cryptographic properties.  An attacker who can control the
   inputs in order to produce a hash collision can attack the
   connection in a variety of other ways.

-Ekr

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip