Re: [Cfrg] request for review of IPsec ESP and AH Usage Guidance

Yoav Nir <> Tue, 02 July 2013 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 030BE21F9F43 for <>; Tue, 2 Jul 2013 08:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O3YOXzHfjyRX for <>; Tue, 2 Jul 2013 08:18:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CC3EF21F9F3D for <>; Tue, 2 Jul 2013 08:18:52 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r62FIh3P011512; Tue, 2 Jul 2013 18:18:43 +0300
X-CheckPoint: {51D2EF53-19-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 18:18:42 +0300
From: Yoav Nir <>
To: David McGrew <>
Thread-Topic: [Cfrg] request for review of IPsec ESP and AH Usage Guidance
Thread-Index: AQHOdzDw7P3QbkGTeUKjeqgDY7zJtZlRTjUA
Date: Tue, 2 Jul 2013 15:18:41 +0000
Message-ID: <>
References: <1372775511.3983.76.camel@darkstar>
In-Reply-To: <1372775511.3983.76.camel@darkstar>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 11a5fd372d39fa03b9345f822de6c536197c768f7d
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Yaron Sheffer <>, "" <>, cfrg <>, Paul Hoffman <>
Subject: Re: [Cfrg] request for review of IPsec ESP and AH Usage Guidance
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jul 2013 15:18:58 -0000

On Jul 2, 2013, at 5:31 PM, David McGrew <> wrote:

> Hello CFRG,
> Yaron, Paul, Wajdi, and I are interested in your input on the "Usage
> Guidance" section in "Cryptographic Algorithm Implementation
> Requirements and Usage Guidance for Encapsulating Security Payload (ESP)
> and Authentication Header (AH)".   This is an active standards-track
> draft in the IPsec working group, which updates the ESP and AH algorithm
> requirements (RFC 4835).  The usage guidance section is new, and it
> offers advice on how to use ESP and AH to achieve cryptographic security
> goals.  
> Quick link:
> thanks,

Hi David.

You've heard these before, but I'll repeat them since you're asking for comments on this list.

- I'm concerned that the only encryption algorithm is AES. Yes, I see that TripleDES-CBC as a MAY, but that is by now the past. AES-128-CBC is 9 times the speed of 3DES (on an Intel platform without AES-NI based on "openssl speed"), and with AES-NI the ratio is likely to jump to 20. With GCM it's even more pronounced. So 3DES cannot be a reasonable alternative to AES. I think we should have some alternative that is at least at the SHOULD level.

- I'm not sure what the point is of the MAY level. We MAY implement anything: SEED, Camellia, GOST. That doesn't help with interoperability

- I'm not sure about AES-GMAC for ESP authentication. Is there a reason why someone would prefer to use AES-CBC or AES-CTR with AES-GMAC rather than AES-GCM? Also, the HMAC-SHA256 algorithm has gained popularity recently (meaning that a lot of customers are asking for it). It runs significantly slower than HMAC-SHA1, but people have stopped reading at "SHA-1 is no longer secure". Still, they're not asking for GMAC, they're asking for SHA-256. So I think a document where the goal is interoperability should focus on what is becoming the de-facto standard as long as it's secure enough.