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

"Gregory M. Lebovitz" <> Tue, 18 November 2008 20:29 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id C954D3A6895; Tue, 18 Nov 2008 12:29:31 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB7023A6895 for <>; Tue, 18 Nov 2008 12:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lS3dPc3QgL03 for <>; Tue, 18 Nov 2008 12:29:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7D0C83A6885 for <>; Tue, 18 Nov 2008 12:29:29 -0800 (PST)
Received: by with SMTP id b25so3042663rvf.49 for <>; Tue, 18 Nov 2008 12:29:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :cc:in-reply-to:references:mime-version:content-type:message-id; bh=jQKjj5fSiWmkRdLsonsDs8mPdVYZZ2+Tz2KxfOEBi8A=; b=ic9eEBCPQwU9Msba65eCoxQvVOS9IIxPI+COMpBGVdTkMWCxu0CPnOfsKENmAauZux ORU4qGltm2dLQ5KPWQ+L3sgDxC2ThrCXs52SKvTEo+F5v2CPhtjE+fYDicK18p0hZlJs 5F+QDGT4K+7WWeUJdum0CjXX+B5AQO1bnz60A=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type:message-id; b=nfcX8FTsDUU5YclQMb22ZK3aMChT+nG7DXBlejgGt3jnm1TDaTeNTTwXNI2ByWW898 ZwYDKD3/jTx7F2/R883Gv3L7vShn86KVtMIDFocv0BZ+tBOXGnfvxF1ypCXrvn5kTS/l oWdXKBui9v+J5OiBm9hMKYezP0ah9czPd/1Go=
Received: by with SMTP id z12mr126169rvf.183.1227040168470; Tue, 18 Nov 2008 12:29:28 -0800 (PST)
Received: from ([]) by with ESMTPS id k41sm9109114rvb.4.2008. (version=SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 12:29:27 -0800 (PST)
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 18 Nov 2008 12:29:13 -0800
To: Eric Rescorla <>, Joe Touch <touch@ISI.EDU>
From: "Gregory M. Lebovitz" <>
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Message-ID: <>
Cc:, tcpm Extensions WG <>, Russ Housley <>, 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Point of process order:  since we've decide that the TCPM/TCP-AO 
effort team will simply receive a decision on MACs from SAAG, may I 
suggest that we take this dicussion to the SAAG list, or do it 
privately between the SAAG folks in the TCP-AO effort, rather than 
pelting the rest of TCPM folks with it? Would you be okay with that?


At 12:16 PM 11/18/2008, Eric Rescorla wrote:
>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

tcpm mailing list