Subject: [secdir] Secdir review of draft-turner-md4-to-historic-08

From: Catherine Meadows <[email-masked]>
Date: Fri, 3 Dec 2010 17:37:31 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document recommends that the MD4 hash algorithm be retired and moved to historic status and gives
the rationale for doing this, namely its known vulnerability to collision and pre-image attacks. The impact is mostly minimal, except
for three Microsoft RFCs that are still supported in various versions of  Windows and the RADIUS and EAP RFCs .  It would be helpful to learn what other algorithms
these OSs and RFCs support.  This would give a better idea of the effect of dropping MD4; if there are other alternatives supported by the OS's
the impact should be minimal here as well.

Other than that, I have no problems with the decision or rationale.  I agree, as I am sure that everyone else does, that MD4
should be retired.  

Some nits:

1.  "Section 6 also discussed" should be "Section 6 also discusses"   This occurs in several places.

2. " The RC4-HMAC is supported in Microsoft's Windows 2000 and 
           later for backwards compatibility with Windows 2000. "
later supported by what?  I assume later versions of Windows, but it is probably a good idea to make this clear.

3. When you say that with one exception the impact of retiring MD4 would be minimal, it would be a good idea to mention that exception upfront.
It is fairly clear after you read the whole impact section  that the exception is the Microsoft RFCs, but nowhere where is that  said explicitly.

4.  I'm not sure wether or not   the discussion of MD4's resistance against key recovery attack really belongs in the impacts section (in the discussion
of RC4-HMAC).  It might give the impression that RC4-HMAC is secure against key recovery, and, given the other attacks found against MD4, it is reasonable
to believe that this security is only temporary.  I would suggest putting this discussion in the security considerations section, and also, wherever it does end up, adding the appropriate
caveats.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]

---

From: Sean Turner <[email-masked]>
Date: Mon, 06 Dec 2010 09:05:31 -0500

Catherine,

Thanks for the review.  Responses inline.

spt

> the impact should be minimal here as well.

I it might be hard to explain what alternatives are in each of the OS's 
because it depends a lot on what version/release/path combo is being 
used.  I think RFC 4757 hints pretty strongly that 
aes256-cts-hmac-sha1-96 is supported because it says to use that alg 
instread of RC4-HMAC.

> 1.  "Section 6 also discussed" should be "Section 6 also discusses"   This occurs in several places.

Fixed

> later supported by what?  I assume later versions of Windows, but it is probably a good idea to make this clear.

r/later/later versions of Windows

> It is fairly clear after you read the whole impact section  that the exception is the Microsoft RFCs, but nowhere where is that  said explicitly.

How about:

The impact of moving MD4 to Historic is minimal with the one exception 
of Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as 
described below.

> to believe that this security is only temporary.  I would suggest putting this discussion in the security considerations section, and also, wherever it does end up, adding the appropriate

I'm hesitant to move the text because it's in there specifically to 
address a comment by Sam Hartman.

My understanding of MD4's use in RC4-HMAC is that MD4 is used to 
generate a key from a password and then that key is used as input to 
HMAC-MD5.  So I am actually saying that RC4-HMAC is secure against key 
recovery attacks but this is entirely because HMAC-MD5 is used.  In 
other words, when HMAC-MD5 is broken then RC4-HMAC is broken.

---

From: Catherine Meadows <[email-masked]>
Date: Mon, 13 Dec 2010 18:21:10 -0500

Hi Sean:

My apologies for my late response.  I've been doing a lot of traveling and, due to an accident with my laptop,
not checking my email as much as I should have.

My response are also inline.

Cathy

On Dec 6, 2010, at 9:05 AM, Sean Turner wrote:

> I it might be hard to explain what alternatives are in each of the OS's because it depends a lot on what version/release/path combo is being used.  I think RFC 4757 hints pretty strongly that aes256-cts-hmac-sha1-96 is supported because it says to use that alg instread of RC4-HMAC.

OK.
> The impact of moving MD4 to Historic is minimal with the one exception of Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as described below.

Sounds good.  
> I'm hesitant to move the text because it's in there specifically to address a comment by Sam Hartman.

OK, the location of the text is not that big a deal.
> 
> My understanding of MD4's use in RC4-HMAC is that MD4 is used to generate a key from a password and then that key is used as input to HMAC-MD5.  So I am actually saying that RC4-HMAC is secure against key recovery attacks but this is entirely because HMAC-MD5 is used.  In other words, when HMAC-MD5 is broken then RC4-HMAC is broken.

OK, I misunderstood.  If I'd read the text a little more carefully I might  have figured it out, but the text is a little ambiguous at first glance.  It could be interpreted to mean
that RC4-HMAC uses MD4 for key protection, but relies on some other property than collision resistance, which perhaps eventually also be broken.  Here is my suggestion for
a clarification, based on what you said:

The RC4-HMAC is supported in Microsoft's Windows 2000 and
           later for backwards compatibility with Windows 2000.  As
           [RFC4757] stated, RC4-HMAC doesn't rely on the collision
           resistance property of MD4, but uses it to generate a key from a password, which is then
           used as input to HMAC-MD5.   For an attacker to recover the
           password from RC4-HMAC, the attacker first needs to recover
           the key that is used with HMAC-MD5.  As noted in
           [ID.turner-md5-seccon-update], key recovery attacks on HMAC-
           MD5 are not yet practical.

Catherine Meadows

---

From: Sean Turner <[email-masked]>
Date: Mon, 13 Dec 2010 19:08:58 -0500

> not checking my email as much as I should have.

No worries.  We still got time ;)  Hope you've been backing up all along.

> My response are also inline.

I'll make the modifications to the paragraph as you suggest.

Cheers,

spt

>>> the rationale for doing this, namely its known vulnerability to
>>> collision and pre-image attacks. The impact is mostly minimal, except
>>> for three Microsoft RFCs that are still supported in various versions
>>> of Windows and the RADIUS and EAP RFCs . It would be helpful to learn
>>> what other algorithms
>>> these OSs and RFCs support. This would give a better idea of the
>>> effect of dropping MD4; if there are other alternatives supported by
>>> the OS's
>> I it might be hard to explain what alternatives are in each of the
>> OS's because it depends a lot on what version/release/path combo is
>> being used. I think RFC 4757 hints pretty strongly that
>>> Other than that, I have no problems with the decision or rationale. I
>>> agree, as I am sure that everyone else does, that MD4
>>> should be retired.
>>>
>>> Some nits:
>>>
>>> later supported by what? I assume later versions of Windows, but it
>>> is probably a good idea to make this clear.
>>
>>> 3. When you say that with one exception the impact of retiring MD4
>>> would be minimal, it would be a good idea to mention that exception
>>> upfront.
>>> It is fairly clear after you read the whole impact section that the
>>> exception is the Microsoft RFCs, but nowhere where is that said
>>> explicitly.
>>
>> How about:
>>
>>> 4. I'm not sure wether or not the discussion of MD4's resistance
>>> against key recovery attack really belongs in the impacts section (in
>>> the discussion
>>> of RC4-HMAC). It might give the impression that RC4-HMAC is secure
>>> against key recovery, and, given the other attacks found against MD4,
>>> it is reasonable
>>> to believe that this security is only temporary. I would suggest
>>> putting this discussion in the security considerations section, and
>>> also, wherever it does end up, adding the appropriate
>>> caveats.
>>
> OK, I misunderstood. If I'd read the text a little more carefully I
> might have figured it out, but the text is a little ambiguous at first
> glance. It could be interpreted to mean
> that RC4-HMAC uses MD4 for key protection, but relies on some other
> property than collision resistance, which perhaps eventually also be
> broken. Here is my suggestion for
> <mailto:[email-masked]>
>