Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated

Martin Rex <mrex@sap.com> Fri, 03 December 2010 21:39 UTC

Return-Path: <mrex@sap.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 385D028C0E2; Fri, 3 Dec 2010 13:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.117
X-Spam-Level:
X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 quxvSazSC7hJ; Fri, 3 Dec 2010 13:39:50 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id A770E28C0FD; Fri, 3 Dec 2010 13:39:48 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oB3Lf1fd023641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Dec 2010 22:41:02 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201012032140.oB3Lex75021511@fs4113.wdf.sap.corp>
Subject: Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated
To: L.Wood@surrey.ac.uk
Date: Fri, 03 Dec 2010 22:40:59 +0100
In-Reply-To: <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> from "L.Wood@surrey.ac.uk" at Dec 3, 10 05:32:23 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: wes@mti-systems.com, iesg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 03 Dec 2010 21:39:54 -0000

L.Wood@surrey.ac.uk wrote:
> 
> I also take issue with RFC4270's claim that:
> 
>    The Internet protocol community needs to
>    migrate in an orderly manner away from SHA-1 and MD5 -- especially
>    MD5 -- and toward more secure hash algorithms.
> 
> which is rather broad, and entirely without the context and qualifiers
> we're discussing. RFC4270 was not written for a general audience,
> but for a security audience.  The Internet _security protocol_ community
> may well need to migrate from these for certain uses (despite there not
> yet being obvious things to move _to_), but RFC4270 and your draft's
> sum take-away message that MD5BADDONOTUSE overstates the case. 

I agree that the above wording of rfc-4270 is BAD.

It should have said:

  The Internet community needs to migrate in an orderly manner away from
  SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms
  for all security-related usages of hash functions in all protocols.




> 
> Despite the fact that, as you say, it's still good for five of seven uses,
> including integrity protection (which gets a mere sentence in 4270 as the
> last of the seven - it's imo an area that is often neglected in protocol
> design).

IMHO there is a serious defect in rfc-4270.  The "integrity protection"
bullet ought to be bullet three, and MD5 is definitely _NOT_ suitable
for anything with the term "integrity" in it.

Integrity protection is terminology that is used in the
security&cryptographic area and this defect of rfc-4270 is going
to create misunderstandings.


MD5 (and SHA-1) are hash functions, and as such, they exhibit probabilistic
collisions for different inputs.  MD5 is still useful for detection of
"accidental" errors due to noise or distortion, but it is not suited
to protect against intentional modification of data by an attacker.

There are other algorithms for detecting "accidental" errors, like
"ECC bits", or CRCs of various sizes, e.g.
   http://en.wikipedia.org/wiki/Cyclic_redundancy_check

Think of MD5 as an alternative to CRC128.



-Martin