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

"Gregory M. Lebovitz" <gregory.ietf@gmail.com> Tue, 18 November 2008 20:29 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C954D3A6895; Tue, 18 Nov 2008 12:29:31 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7023A6895 for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 12:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
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 lS3dPc3QgL03 for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 12:29:29 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 7D0C83A6885 for <tcpm@ietf.org>; Tue, 18 Nov 2008 12:29:29 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so3042663rvf.49 for <tcpm@ietf.org>; Tue, 18 Nov 2008 12:29:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.140.202.12 with SMTP id z12mr126169rvf.183.1227040168470; Tue, 18 Nov 2008 12:29:28 -0800 (PST)
Received: from Gregory-T60.gmail.com ([130.129.95.186]) by mx.google.com with ESMTPS id k41sm9109114rvb.4.2008.11.18.12.29.24 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 12:29:27 -0800 (PST)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Nov 2008 12:29:13 -0800
To: Eric Rescorla <ekr@networkresonance.com>, Joe Touch <touch@ISI.EDU>
From: "Gregory M. Lebovitz" <gregory.ietf@gmail.com>
In-Reply-To: <20081118201652.0D9DE75D25F@kilo.rtfm.com>
References: <49231C13.10303@isi.edu> <20081118201652.0D9DE75D25F@kilo.rtfm.com>
Mime-Version: 1.0
Message-ID: <492325a7.29578c0a.7edf.7e39@mx.google.com>
Cc: pasi.eronen@nokia.com, tcpm Extensions WG <tcpm@ietf.org>, Russ Housley <housley@vigilsec.com>, Tim Polk <tim.polk@nist.gov>
Subject: Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Ekr,
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?

Gregory.

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.
>
>http://eprint.iacr.org/2006/187
>http://www.springerlink.com/content/00w4v62651001303/
>
>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"
>
>-Ekr
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm