Re: Security Area Response to Hash Function "Breaks"

[Russ Housley <housley@xxxxxxxxxxxx>]

Magnus:

The NIST recommendation is to move away from SHA-1 by 2010, simply 
due to its size.  NIST made this recommendation before the flaws in 
SHA-1 were discovered.  SHA-1 is a 160-bit hash.  MD5 is a 128-bit 
hash.  Can you explain why the smaller hash value is acceptable in 
the SACRED protocol context beyond 2010?

Russ

At 09:56 AM 11/30/2005, Magnus Nyström wrote:

> Please see below.
>
> In light of recent cryptanalytic results on hash functions, each 
> IETF working group is asked to provide an analysis of its use of 
> hash functions.
>
> SACRED rely on DIGEST-MD5, but IMO SACRED does not become vulnerable 
> to attacks due to recent results on MD5. The reasons are that in 
> Digest-MD5, hashes are either done on nonces provided both by the 
> client and the server or on the username and password selected by 
> the client. Hence an attacker cannot perform a collision attack - in 
> the former because the nonces are not known in advance and in the 
> latter case since it would be equivalent to finding the password, at 
> which point he could impersonate the user anyway.
>
> Comments, anyone?
>
> -- Magnus
>
> On Thu, 24 Nov 2005, Russ Housley wrote:
>
> > Below is a summary of the discussion that occurred at the SAAG 
> > session during IETF 64. When MD5 or SHA-1 is used to support 
> > digital signatures or used by itself, recent cryptographic research 
> > findings indicate the need for a transition.  Therefore, I 
> > encourage all IETF WGs to follow the lead of the Security Area in 
> > transition away from MD5 and SHA-1 toward SHA-256.
> > TCP-MD5 is one example where a transition is needed.  In this case, 
> > a transition to HMAC-SHA-1 or HMAC-SHA-256 seems like a reasonable move.
> > Russ Housley
> > Security Area Director
> > = = = = = = = = = =
> > During IETF 64, the Security Area Advisors Group (SAAG) session was 
> > dedicated to the discussion of hash function "breaks" and the 
> > appropriate IETF response to this situation.
> > Eric Rescorla from gave a presentation on deploying a new hash 
> > function.  The presentation is based on a paper that Eric 
> > co-authored with Steve Bellovin. All of the IETF security protocols 
> > that were analyzed required work in order to support transition to 
> > new hash functions.  The paper is available at 
> > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
> > Russ Housley gave a presentation on the Security Area response to 
> > these hash function "breaks."  We should "walk, not run."  This is 
> > not a problem yet, but as the attacks are improved it will become a 
> > problem.  Russ shared his conclusions from the NIST Hash Workshop 
> > held on October 31st and November 1st.
> >  * SHA-1 should be reach its "end of life" digital
> >    signatures by 2010;
> >  * The IETF cannot expect any new standard hash functions
> >    before 2010;
> >  * The security ADs have decided that we need to transition
> >    to SHA-256 now; and
> >  * There will probably be another transition once a new hash
> >    function is available.
> > The IETF needs to become good at transitions as we have at least 
> > two.  Within the Security Area, protocols with active WGs will be 
> > analyzed within those WGs; others will be handled in SAAG.  The 
> > following directive to WG Chairs in the Security Area was given:
> >  * Perform Bellovin-Rescorla analysis on every protocol in
> >    the WG by IETF 65; and
> >  * Start standards work on transition to SHA-256, but plan
> >    for future transitions.
> > In some cases it may be appropriate to transition away from hash 
> > functions, perhaps to a message authentication code.