Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO

Eric Rescorla <> Tue, 18 November 2008 20:16 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 01C9F3A67D6; Tue, 18 Nov 2008 12:16:59 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FCD53A68BF for <>; Tue, 18 Nov 2008 12:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.395
X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EcXYvfGPqkdU for <>; Tue, 18 Nov 2008 12:16:53 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 100543A67D0 for <>; Tue, 18 Nov 2008 12:16:53 -0800 (PST)
Received: from kilo-2.local (localhost []) by (Postfix) with ESMTP id 0D9DE75D25F; Tue, 18 Nov 2008 14:16:52 -0600 (CST)
Date: Tue, 18 Nov 2008 14:16:51 -0600
From: Eric Rescorla <>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <>
Cc: Russ Housley <>, tcpm Extensions WG <>,, Tim Polk <>
Subject: Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

At Tue, 18 Nov 2008 11:48:35 -0800,
Joe Touch wrote:
> TCP-AO needs to make two decisions with respect to MAC algorithms:
> select algorithms for the current specification; and establish
> criteria for specification of MAC algorithms in the future.  To be
> honest, there are numerous MAC algorithms that could satisfy TCP-AO's
> security requirements.  Pragmatic issues like performance and current
> code bases need to be factored in as well.
> The two most attractive options for generating the MAC are AES 128 in
> the cipher-based message authentication code (CMAC) mode and the
> SHA-1 Hash-based Message Authentication Code (HMAC).   Both options
> provide a high level of security and efficiency.  The AES 128 CMAC is
> potentially more efficient, particularly in hardware, but SHA-1 HMAC
> is more widely used in Internet protocols and in most cases could be
> supported with little or no additional code.
> Another aspect of the algorithm selection is whether the tags should
> be truncated.  CMAC-AES-128 produces a 128 bit MAC, and HMAC SHA-1
> produces a 160 bit result.  The MAC can be truncated to 96 bits
> provide a reasonable tradeoff between security and message size.  So,
> the algorithms that were in draft-bonica are entirely reasonable
> choices: AES-128-CMAC-96 and HMAC-SHA-1-96.  For interoperability,
> the working group needs to either specify one MAC algorithm as a MUST
> and the other as a SHOULD, or specify MUST implement for both
> algorithms.
> Note that the security issues driving the migration from SHA-1 to
> SHA-256 for digital signatures do not apply here.  The security
> strength of SHA-1 HMACs should be sufficient for the foreseeable
> future.

I'm sorry to be difficult, but I don't think that this is quite so
clear. The relevant cite here is:

Jongsung Kim and Alex Biryukov and Bart Preneel and Seokhie Hong,
"On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",
SCN 2006.

While it's clear that the attacks aren't practical on SHA-1, or probably
MD5, it's not like the types of analysis people are mounting don't
potentially pose a concern for HMAC forgery if they were significantly
improved, so I don't think that it's fair to say that the "security issues
driving the migration... don't apply here"

tcpm mailing list