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

Yoav Nir <ynir@checkpoint.com> Tue, 02 July 2013 15:18 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030BE21F9F43 for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 08:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3YOXzHfjyRX for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 08:18:53 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CC3EF21F9F3D for <cfrg@irtf.org>; Tue, 2 Jul 2013 08:18:52 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (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 DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 18:18:42 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: David McGrew <mcgrew@cisco.com>
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: <30837097-4DB3-495C-86F4-42C76B634864@checkpoint.com>
References: <1372775511.3983.76.camel@darkstar>
In-Reply-To: <1372775511.3983.76.camel@darkstar>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.28]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 11a5fd372d39fa03b9345f822de6c536197c768f7d
Content-Type: text/plain; charset="us-ascii"
Content-ID: <087532E80BBCF54CA7AC96389C9329C5@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "wajdi.k.feghali@intel.com" <wajdi.k.feghali@intel.com>, cfrg <cfrg@irtf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Cfrg] request for review of IPsec ESP and AH Usage Guidance
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 15:18:58 -0000

On Jul 2, 2013, at 5:31 PM, David McGrew <mcgrew@cisco.com> 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:
> http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/?include_text=1
> 
> 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.

Yoav