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

Sean Turner <> Tue, 14 December 2010 00:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B397C3A6E19 for <>; Mon, 13 Dec 2010 16:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mDaIyWQx8RVj for <>; Mon, 13 Dec 2010 16:07:23 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id E30DB3A6E0F for <>; Mon, 13 Dec 2010 16:07:22 -0800 (PST)
Received: from [] by with NNFMP; 14 Dec 2010 00:08:59 -0000
Received: from [] by with NNFMP; 14 Dec 2010 00:08:59 -0000
Received: from [] by with NNFMP; 14 Dec 2010 00:08:59 -0000
Received: (qmail 15152 invoked from network); 14 Dec 2010 00:08:59 -0000
Received: from thunderfish.local (turners@ with plain) by with SMTP; 13 Dec 2010 16:08:58 -0800 PST
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: 09pqKHMVM1lG9kpcfI7jy6tIdqGydhKJynv66YQGqmkMtOE XgXXm9HMBX7QAh98lMDx7OdFqQnwF8QPXQyzxoYl4QkBHHU3EAY.GqInHA7K 92y9J5_l6feFPpo92iyzxl8RNNjh771xh21GlFT6TpSBZWEqSLK.GEsaHhnx aS4dMoq1LU2edUx7L80fvSPqqz20nTUx1V0i9fsmM_v2LI3X3sqTk3Ad_jVi .eRSEUXaI0dd1DRQvdleN477J_KFGVYWc9yLBgKTBUr7IZFMxbdPg6jmLOiZ wA_q8Q3htnK8weXReQzKVxgz9I4OVR1kKdtXvQdjpVR4atnkgci8tWX2WSsu xyjJD3iPideX8tMrDADUJY76SzO0UEda1IXuBDlZVwivW5k5M2EQDv5a9Q6G fDpYfbVnoyUkyPym2XyhxQWzcxiKvKPuXwQ.YCU.E
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Mon, 13 Dec 2010 19:08:58 -0500
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Catherine Meadows <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Dec 2010 00:07:24 -0000

On 12/13/10 6:21 PM, Catherine Meadows wrote:
> 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.

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.



> Cathy
> On Dec 6, 2010, at 9:05 AM, Sean Turner wrote:
>> Catherine,
>> Thanks for the review. Responses inline.
>> spt
>> On 12/3/10 5:37 PM, Catherine Meadows wrote:
>>> 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.
>> 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.
>>> 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.
>> Fixed
>>> 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.
>> r/later/later versions of Windows
>>> 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:
>> 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.
>>> 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.
>> 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
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email:
> <>