Subject: Re: Security Area Response to Hash Function "Breaks"

From: Magnus Nyström <[email-masked]>
Date: Wed, 30 Nov 2005 15:56:03 +0100 (W. Europe Standard Time)

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.

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 Nov 2005 10:27:32 -0500

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
>
>>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 
>>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.
>>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:
>>In some cases it may be appropriate to transition away from hash 
>>functions, perhaps to a message authentication code.
>

---

From: Magnus Nyström <[email-masked]>
Date: Wed, 30 Nov 2005 16:46:07 +0100 (W. Europe Standard Time)

In the context of Digest-MD5, we're mostly concerned about pre-image 
resistance. I further assume that the entropy of the underlying password 
is less than 128 bits.

-- Magnus

On Wed, 30 Nov 2005, Russ Housley wrote:

> 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
>
>> working group is asked to provide an analysis of its use of hash functions.
>> 
>> 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
>> 
>>> 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.
>>> 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.
>>> 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: