Re: Security Area Response to Hash Function "Breaks"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--2952815-31068-1133426931=:2704
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

That said, I of course would not have anything against a move to, e.g., a=
=20
new DIGEST-SHA256 (even though I personally would have preferred a strong=
=20
password-based authentication/key exchange mechanism such as EKE).

In light of the hash function results, moving away from MD5 and SHA-1=20
(with reason) seems prudent practice. My initial posting here had the=20
intent of examining whether SACRED faces any direct problems due to the=20
results; my conclusion at this time is that SACRED does not.

-- Magnus

On Wed, 30 Nov 2005, Magnus Nystr=F6m wrote:

> In the context of Digest-MD5, we're mostly concerned about pre-image=20
> resistance. I further assume that the entropy of the underlying password =
is=20
> less than 128 bits.
>
> -- Magnus
>
> On Wed, 30 Nov 2005, Russ Housley wrote:
>
>> Magnus:
>>=20
>> The NIST recommendation is to move away from SHA-1 by 2010, simply due t=
o=20
>> its size.  NIST made this recommendation before the flaws in SHA-1 were=
=20
>> discovered.  SHA-1 is a 160-bit hash.  MD5 is a 128-bit hash.  Can you=
=20
>> explain why the smaller hash value is acceptable in the SACRED protocol=
=20
>> context beyond 2010?
>>=20
>> Russ
>>=20
>> At 09:56 AM 11/30/2005, Magnus Nystr=F6m wrote:
>>=20
>>> Please see below.
>>>=20
>>> In light of recent cryptanalytic results on hash functions, each IETF=
=20
>>> working group is asked to provide an analysis of its use of hash=20
>>> functions.
>>>=20
>>> SACRED rely on DIGEST-MD5, but IMO SACRED does not become vulnerable to=
=20
>>> attacks due to recent results on MD5. The reasons are that in Digest-MD=
5,=20
>>> hashes are either done on nonces provided both by the client and the=20
>>> server or on the username and password selected by the client. Hence an=
=20
>>> attacker cannot perform a collision attack - in the former because the=
=20
>>> nonces are not known in advance and in the latter case since it would b=
e=20
>>> equivalent to finding the password, at which point he could impersonate=
=20
>>> the user anyway.
>>>=20
>>> Comments, anyone?
>>>=20
>>> -- Magnus
>>>=20
>>> On Thu, 24 Nov 2005, Russ Housley wrote:
>>>=20
>>>> Below is a summary of the discussion that occurred at the SAAG session=
=20
>>>> during IETF 64. When MD5 or SHA-1 is used to support digital signature=
s=20
>>>> or used by itself, recent cryptographic research findings indicate the=
=20
>>>> need for a transition.  Therefore, I encourage all IETF WGs to follow =
the=20
>>>> lead of the Security Area in transition away from MD5 and SHA-1 toward=
=20
>>>> SHA-256.
>>>> TCP-MD5 is one example where a transition is needed.  In this case, a=
=20
>>>> transition to HMAC-SHA-1 or HMAC-SHA-256 seems like a reasonable move.
>>>> Russ Housley
>>>> Security Area Director
>>>> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>>>> During IETF 64, the Security Area Advisors Group (SAAG) session was=20
>>>> dedicated to the discussion of hash function "breaks" and the appropri=
ate=20
>>>> IETF response to this situation.
>>>> Eric Rescorla from gave a presentation on deploying a new hash functio=
n.=20
>>>> The presentation is based on a paper that Eric co-authored with Steve=
=20
>>>> Bellovin. All of the IETF security protocols that were analyzed requir=
ed=20
>>>> work in order to support transition to new hash functions.  The paper =
is=20
>>>> available at http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
>>>> Russ Housley gave a presentation on the Security Area response to thes=
e=20
>>>> hash function "breaks."  We should "walk, not run."  This is not a=20
>>>> problem yet, but as the attacks are improved it will become a problem.=
=20
>>>> Russ shared his conclusions from the NIST Hash Workshop held on Octobe=
r=20
>>>> 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.=
=20
>>>> Within the Security Area, protocols with active WGs will be analyzed=
=20
>>>> within those WGs; others will be handled in SAAG.  The following=20
>>>> 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=20
>>>> functions, perhaps to a message authentication code.
>>>=20
>>=20
>
--2952815-31068-1133426931=:2704--