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

[Robert Sparks <rjsparks at estacado.net>]

To make this a little less vague - what the draft has right now is:

>   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.  An MD5 [RFC1321] hash expressed in
>    hexadecimal (base64 is not permissible for a token) is a reasonable
>    choice of a hash function.  Any hash function chosen should have  
> the
>    property of very low probability of collision.  Hashes resulting in
>    fewer than 128 bits are not recommended.

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


On Oct 3, 2006, at 2:34 PM, Cullen Jennings wrote:

> So my vague recollection of where we are:
>
> 1) we all agree cryptographic hash would likely not be a good choice
> 2) we agree the spec does not need to mandate any particular hash  
> or length
> 3) it would help implementors if we gave advice of what a  
> reasonable choice might be (in a non normative way)
>
> So far, I have not see a suggestion of what a good choice should  
> be, I don't have a specific one to recommend, but I think the draft  
> should propose a reasonable choice and a reasonable bit length  
> because every implementer I know is going to do exactly whatever  
> the draft shows in it's examples.
>
>
>
> On Oct 3, 2006, at 11:36 AM, Robert Sparks wrote:
>
> > There are other changes to the draft that I've agreed to make, so  
> > there will be a new version (shortly).
> >
> > This question isn't pinned down yet though. The draft _doesn't_  
> > require any specific hash. It gives advice on a reasonable choice.
> > It goes further to characterize properties of other choices an  
> > implementation might make, where it trips over this bit-count that  
> > gave
> > people different kinds of heatburn.
> >
> > I propose just pulling the bit-length description and instead  
> > point to the lack-of-collision property that folks need to take  
> > into account.
> > We are already careful not to say "cryptographic", but I'll  
> > probably add a comment making the lack-of-cryptographic-requirement
> > more explicit.
> >
> > RjS
> >
> > On Oct 3, 2006, at 1:21 PM, Dean Willis wrote:
> >
> > > Cullen Jennings wrote:
> > > > I don't think we should require any specific hash but I think it  
> > > > would be nice to give implementors some advice on what might be  
> > > > a reasonable choice.
> > >
> > > So does this mean we need a change to the draft, or did we decide  
> > > to stand with the current text?
> > >
> > > --
> > > Dean


_______________________________________________
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