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

[Cullen Jennings <fluffy at cisco.com>]

inline but yes basically agree with you ...

On Oct 4, 2006, at 2:35 PM, Michael Thomas wrote:

> Cullen Jennings wrote:
>
> > On Oct 3, 2006, at 12:52 PM, Robert Sparks wrote:
> >
> > > I take it you are explicitly objecting to the statement that MD5  
> > > is  a reasonable non-normatively specified choice?
> > > You have also clearly objected to 128 as a suggestion (The text   
> > > does NOT mandate a length).
> > >
> > > RjS
> >
> >
> > Yes - MD5 is a cryptographic hash and I thought we all agreed  
> > that  use off cryptographic hash was not the best choice. If we  
> > think  cryptographic hash ideas are a good idea, then we need to  
> > explain why.
> >
> > Using a cryptographic hash, even in an example, is a huge red  
> > flag  for any security person reviewing this. The fact that we  
> > used this  particular one which has significant security issues,  
> > is a even  bigger issue.
>
> Uh, no. These aren't even remotely comparable. I'm going to make a  
> big leap here
> and guess that people aren't trying to actively _attack_ these  
> forking hashes. _That's_
> the problem with MD5 with security. If you're just using it as a  
> _hashing_ algorithm
> that has a low probability of collisions, it's just fine. That is:  
> unless you're going to
> say that the forking hash needs to be resisitant to collisions from  
> an attacker's chosen
> text to do something nefarious, the problems with MD5 (or SHA1)  
> don't apply.

yes - agree - all we need is something with low probability of  
collision, and the value of  "low" is based on probability of call  
failing and having to be retried, not some security violation

> > Partially I think MD5 is totally lame to use here  because it is  
> > slow and offer no advantages over better things and  partially I  
> > am trying to avoid any delays due to security review  where  
> > someone points out we should not be using MD5 in new protocols.
>
> The only knock in my mind is that it may be slower than something  
> else,

Yes - I should have been clearer - that was my only concern. And even  
with that, I've never been a believer that the performance mattered  
much but many people in the WG have expressed that we have to do O 
(N^2) where N=30  or 70 depending on who you follow and this was a  
huge deal. I just wanted to take this performance argument off the  
table.

> but I'd
> worry a great deal about the "something else" if collisions are a  
> problem. Just randomly
> inventing a good hashing algorithm with good collision properties  
> especially with
> similar chosen text is not exactly the easiest thing to do.

100% agree - I'm not a fan of roll your own solution to hashes.  
Actually people still make fun of me for a project where I created in  
a hash table that only generated even numbers. Since then I have  
always been concerned about getting burned from things I rolled myself.

> Since you're relying on this
> for carrying state, I think it's a bad idea to not at least do a  
> SHOULD level algorithm(s)
> and be very certain that the algorithm you choose actual has the  
> collision resistance
> needed. I'm not an expert here by any means, but my recollection is  
> that CRC does
> NOT have very good properties that way.

CRC has poor whitening characteristics but it collision distribution  
if fairly uniform. All of this is weighted off against how many bits  
collision detection do we use. Keep in min that we have up to 70  
things that we don't want to collide with a something like 1 in fives  
nines probability of collision. WIth a good hash we could likely do  
this in something like 15 bits (WAG), with a crappy hash we need a  
few more bits. We are talking about using insanely more bits than  
this (32 bits) so I'm not that worried. I would be worried with a  
CRC16. Also, as you point out, we are not trying to protect against a  
case where an attacker deliberately generates a collision in which  
case CRC would be a very bad choice.

I think there are a huge number of things that could work fine and  
don't care what we choose - but since people are claiming that we  
should not use this loop detection because it is slow, I want the  
some reasonable fast hash to compare to.


>       Mike
>
>
> >   If the we can't figure out a reasonable hash to suggest, how  
> > should  an implementer figure out what to use. I've been trying to  
> > say, I  don't care what but don't choose a cryptographic one. If  
> > people have  a good reason for wanting MD5, I'm glad to listen but  
> > I just had not  heard the reason yet.
> >
> >
> >
> >
> > _______________________________________________
> > 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

_______________________________________________
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