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

Sean Turner <turners@ieca.com> Tue, 14 December 2010 00:07 UTC

Return-Path: <turners@ieca.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B397C3A6E19 for <secdir@core3.amsl.com>; Mon, 13 Dec 2010 16:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDaIyWQx8RVj for <secdir@core3.amsl.com>; Mon, 13 Dec 2010 16:07:23 -0800 (PST)
Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224]) by core3.amsl.com (Postfix) with SMTP id E30DB3A6E0F for <secdir@ietf.org>; Mon, 13 Dec 2010 16:07:22 -0800 (PST)
Received: from [98.139.52.196] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 14 Dec 2010 00:08:59 -0000
Received: from [98.139.52.166] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 14 Dec 2010 00:08:59 -0000
Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 14 Dec 2010 00:08:59 -0000
X-Yahoo-Newman-Id: 307795.85666.bm@omp1049.mail.ac4.yahoo.com
Received: (qmail 15152 invoked from network); 14 Dec 2010 00:08:59 -0000
Received: from thunderfish.local (turners@96.231.123.240 with plain) by smtp112.biz.mail.re2.yahoo.com 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: <4D06B59A.4040700@ieca.com>
Date: Mon, 13 Dec 2010 19:08:58 -0500
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>
References: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> <4CFCEDAB.9040909@ieca.com> <C07A6B54-F379-4854-8565-557709CB1D10@nrl.navy.mil>
In-Reply-To: <C07A6B54-F379-4854-8565-557709CB1D10@nrl.navy.mil>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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.

Cheers,

spt

> 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: catherine.meadows@nrl.navy.mil
> <mailto:catherine.meadows@nrl.navy.mil>
>