Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard

Hugo Krawczyk <hugo@ee.technion.ac.il> Sat, 10 July 2004 03:48 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02042 for <ipsec-archive@lists.ietf.org>; Fri, 9 Jul 2004 23:48:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7hB-0006b1-4N; Fri, 09 Jul 2004 22:34:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj5Ru-0000fn-Ka for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 20:10:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15646 for <ipsec@ietf.org>; Fri, 9 Jul 2004 20:10:31 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj5Ro-000229-49 for ipsec@ietf.org; Fri, 09 Jul 2004 20:10:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj5Qi-0001ay-00 for ipsec@ietf.org; Fri, 09 Jul 2004 20:09:25 -0400
Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx with esmtp (Exim 4.12) id 1Bj5PD-0000qD-00; Fri, 09 Jul 2004 20:07:51 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 44B42F78EE; Sat, 10 Jul 2004 03:07:51 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il)
Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27972-01-36; Sat, 10 Jul 2004 03:07:51 +0300 (IDT)
Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 5192EF78CA; Sat, 10 Jul 2004 03:07:46 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il)
Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i6A0A8CR024656; Sat, 10 Jul 2004 03:10:08 +0300 (IDT)
Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i6A0A7jW024653; Sat, 10 Jul 2004 03:10:08 +0300 (IDT)
Date: Sat, 10 Jul 2004 03:10:07 +0300
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
Subject: Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard
In-Reply-To: <Pine.LNX.4.44.0407100019120.12327-100000@lien.esat.kuleuven.ac.be>
Message-ID: <Pine.GSO.4.44_heb2.09.0407100257460.22363-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Virus-Scanned: by amavisd-new at technion.ac.il
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Cc: ipsec@ietf.org, iesg@ietf.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Bart,

I am aware of most of the results you mention. Yet, they do not seem to
show any particular weakness of MD5 in the HMAC contest (not more than
SHA-1). Of course, being conservative is a good thing in cryptography but
in this case arguing against HMAC-MD5 may be too conservative.

First, as far as I can see there is no indication that we are closer to a
break of HMAC-MD5 than to a break of HMAC-SHA1 (which is what we are
comparing with).  Second, MAC functions have the nice property that their
break affects security of those using the function AFTER the break, not
those that used it before (this is in sharp contrast to encryption);
therefore having HMAC-SHA1 in an implementation (and this is what ipsec is
demanding by having HMAC-SHA1 as a MUST) allows to move to HMAC-SHA1 if
necessary (i.e. if serious deficiencies of MD5 are found that effect its
security in the context of HMAC). Third, the better speed of MD5 is
significant in some environments (and only for those the use of HMAC-MD5
should be considered).

Finally, I like your last suggestion: a concrete proposal based on
universal hashing for those that need truly fast authentication.
However, I am disappointed by the lack of perceived need for such speeds.
(Say 5-10 times faster than MD5). If anyone has a clear need for such
functions (in particular in the ipsec world) I'd like to know.

Hugo

On Sat, 10 Jul 2004, Bart Preneel wrote:

> Hugo,
>
> I am not so sure that we should strenghten the recommendation for HMAC-MD5.
>
> 1) Very few researchers work on hash functions of the MDx-type, and I am
> aware of only 1 (not yet published) result on "deviation of randomness"
> for these functions; hence the absence of results should not be
> interpreted as an indication of security.
>
> 2) The little effort that has been spent has resulted in some progress
> in the last 2 years:
>
> Saarinen has shown at FSE 2003 that there are some problems when SHA-1
> and MD5 would be used as block ciphers (keyed by the message input -
> feedforward omitted); collisions have been found for 3 rounds of HAVAL
> (Biryukov et al., Asiacrypt 2003); at Crypto 2004 Eli Biham and Rafi Chen
> will present near-collisions of SHA-0 (they can also break now 36 rounds
> of SHA-1).
>
> None of these attacks forms a direct threat to HMAC-MD5, but these
> results show that after 10 years our ability to attack this type of functions
> keeps improving; nothing indicates that this progress will stop in
> the next years.
>
> 3) Nobody has so far attempted to apply algebraic attacks to these
> objects; these attacks have been rather successful against stream
> ciphers, even if their applicability for block ciphers is currently
> unclear.
>
> Once problems are discovered, getting rid of an algorithm is difficult,
> which is a reason to be conservative (some components in the banking world
> are still in the process of being upgraded from DES to triple-DES).
>
> Finally, it seems that if performance is really an issue, one should
> start working on developing a concrete solution using universal
> hash function-based constructions.
>
> --Bart
>
> On Thu, 8 Jul 2004, Hugo Krawczyk wrote:
>
> > Draft draft-ietf-ipsec-esp-ah-algorithms-01.txt
> > specifies HMAC-MD5 as MAY (in the list of authentication algorithms).
> >
> > Given that 8 years after the invention of HMAC and 8 years after
> > Dobbertin's attacks on MD5 there is no single piece of evidence (big or
> > small) against the use of HMAC-MD5, and given that HMAC-MD5 is close to
> > twice the speed of HMAC-SHA1, then I suggest to upgrade HMAC-MD5 to SHOULD
> > (it is good to make it available for applications that need the speed,
> > especially in authentication-only configurations (are there any?)
> >
> > Just a suggestion. Feel free to ignore.
> >
> > Hugo
> >
> > On Wed, 23 Jun 2004, The IESG wrote:
> >
> > > The IESG has received a request from the IP Security Protocol WG to consider
> > > the following document:
> > >
> > > - 'Cryptographic Algorithm Implementation Requirements For ESP And AH '
> > ><draft-ietf-ipsec-esp-ah-algorithms-01.txt> as a Proposed Standard
> > >
> > > The IESG plans to make a decision in the next few weeks, and solicits
> > > final comments on this action.Please send any comments to the
> > > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-07.
> > >
> > > The file can be obtained via
> > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt
> > >
> > >
> > > _______________________________________________
> > > Ipsec mailing list
> > > Ipsec@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ipsec
> > >
> >
> >
> >
> > _______________________________________________
> > Ipsec mailing list
> > Ipsec@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipsec
> >
>
>
>
>


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec