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

Yoav Nir <ynir@checkpoint.com> Tue, 02 July 2013 15:52 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 C876C21F9EFF for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 08:52:12 -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 KM13abT8Np0r for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 08:52:03 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15F2F21F9EFB for <cfrg@irtf.org>; Tue, 2 Jul 2013 08:52:02 -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 r62FptEC023728; Tue, 2 Jul 2013 18:52:00 +0300
X-CheckPoint: {51D2F71B-C-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:51:55 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: [Cfrg] request for review of IPsec ESP and AH Usage Guidance
Thread-Index: AQHOdzDw7P3QbkGTeUKjeqgDY7zJtZlRTjUAgAAECACAAATkAA==
Date: Tue, 02 Jul 2013 15:51:55 +0000
Message-ID: <D3B1C8DB-3411-4684-A13F-D252BF67CE5F@checkpoint.com>
References: <1372775511.3983.76.camel@darkstar> <30837097-4DB3-495C-86F4-42C76B634864@checkpoint.com> <ECC9C873-595E-42E9-B18C-5DB52F3A0DCE@vpnc.org>
In-Reply-To: <ECC9C873-595E-42E9-B18C-5DB52F3A0DCE@vpnc.org>
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: 114c58a7ad18a6769f02efdb90a094e4f65b1c3f97
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4C439387D98CDF46B0F95B548069EACD@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: cfrg <cfrg@irtf.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:52:13 -0000

On Jul 2, 2013, at 6:33 PM, Paul Hoffman <paul.hoffman@vpnc.org>
 wrote:

> On Jul 2, 2013, at 8:18 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> 
>> - 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.
> 
> ...and yet no alternative seemed reasonable enough for you to suggest. :-) Should we either (a) delay this document until there is a widely-agreed-on alternative that is better than 3DES or (b) pick something now that is not widely-agreed-on and try to promote it? Neither seems like a good option to me.

"openssl speed" has Camellia at 70% the speed of AES. And while it's not widely implemented in IPsec, its TLS ciphersuites are implemented and enabled by default in both Chrome and Firefox, as well as in OpenSSL. If I'm not mistaken a default Firefox, and an out-of-the-box Apache server with ModSSL will use Camellia.

>> - 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
> 
> Documenting at least one MAY-level algorithm shows that an implementation must not assume that there is only one code point that it will need to ever care about.

OK, but this makes "SHOULD NOT+" strange. Am I required to remove it from my library to make it compliant?  Can I still keep the 40-bit variant of CAST that I have there? It's OK to publish a separate die-die-die document for DES like the one for MD5, but in this document?

>> - 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.
> 
> Having the document list the rationale for using GMAC instead of an HMAC would indeed be good.

I know, I know. Because it's faster. But we have GCM for that.

Yoav