IETF Logo Mail Archive

RE: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC

Christian Huitema <huitema@microsoft.com> Wed, 08 December 2010 21:23 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CA53A68B7; Wed, 8 Dec 2010 13:23:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.116
X-Spam-Level:
X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 V3wnHL9C4ECo; Wed, 8 Dec 2010 13:23:48 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6D51D3A687D; Wed, 8 Dec 2010 13:23:45 -0800 (PST)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Dec 2010 13:25:06 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 8 Dec 2010 13:25:06 -0800
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.228]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 8 Dec 2010 13:25:05 -0800
From: Christian Huitema <huitema@microsoft.com>
To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov>, Francis Dupont <Francis.Dupont@fdupont.fr>, "L.Wood@surrey.ac.uk" <L.Wood@surrey.ac.uk>
Subject: RE: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
Thread-Topic: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
Thread-Index: AQHLlxRXkp8826zdvUCPqRshSRLcfZOXDdgQ
Date: Wed, 08 Dec 2010 21:25:05 +0000
Message-ID: <CEBCE3CF81D2D441B14B84256C3C468107AE1E@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: Your message of Fri, 03 Dec 2010 17:32:23 GMT. <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> , <201012081455.oB8EthVY034055@givry.fdupont.fr> <C304DB494AC0C04C87C6A6E2FF5603DB4823358384@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB4823358384@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "wes@mti-systems.com" <wes@mti-systems.com>, "iesg@ietf.org" <iesg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 21:23:59 -0000

The issue would be a whole lot easier to resolve if we had an agreed upon algorithm for the "non security" usages. CRC64 comes to mind.



-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Sent: Wednesday, December 08, 2010 12:08 PM
To: Francis Dupont; L.Wood@surrey.ac.uk
Cc: wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org
Subject: RE: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC 

The logic doesn't make sense in this position.  "Crypto modules can't use MD5, thus no protocols at all should use MD5."


________________________________________
From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Francis Dupont [Francis.Dupont@fdupont.fr]
Sent: Wednesday, December 08, 2010 9:55 AM
To: L.Wood@surrey.ac.uk
Cc: wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org
Subject: Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated        Security Considerations for the MD5 Message-Digest and the      HMAC-MD5 Algorithms) to Informational RFC

I have a concern about no security usages of MD5 for practical reasons:
in some environments, including US Gov, crypto implementations (e.g., FIPS 140-2 HSMs) are required to not support MD5 so you can have to choose between a compliant application and a conformant crypto, for instance for DNS TSIG...

So IMHO it is still a good idea to avoid MD5 in any uses, even when it is still far to have been proved insecure or for an use which is not about security.

This could be caught by the "DEPRECATED" keyword in the registry but this registry doesn't seem to have usage entries?!

To conclude I am fine with the implicit conclusion of the I-D to not use MD5 or HMAC-MD5 in new protocols.

Thanks

Francis.Dupont@fdupont.fr

PS: I am the gen-art reviewer for this document too.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email