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

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Tue, 02 July 2013 20:02 UTC

Return-Path: <prvs=0895b2fc78=uri@ll.mit.edu>
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 DEA6E21F9B18 for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 13:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.223
X-Spam-Level:
X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
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 aA6v6xbxNNsF for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 13:01:55 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id AC85221F9B17 for <cfrg@irtf.org>; Tue, 2 Jul 2013 13:01:55 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r62K1jbM032224; Tue, 2 Jul 2013 16:01:45 -0400
MIME-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
In-Reply-To: <A574FAAC-03C8-4E04-9827-131A114B755B@checkpoint.com>
Date: Tue, 02 Jul 2013 16:01:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <BEC9EE61-2B4B-45D3-BED2-45688F34FF29@ll.mit.edu>
References: <1372775511.3983.76.camel@darkstar> <30837097-4DB3-495C-86F4-42C76B634864@checkpoint.com> <ECC9C873-595E-42E9-B18C-5DB52F3A0DCE@vpnc.org> <D3B1C8DB-3411-4684-A13F-D252BF67CE5F@checkpoint.com> <5A32D67C-0EAD-4A93-805C-DCA134553279@vpnc.org> <A574FAAC-03C8-4E04-9827-131A114B755B@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1283)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-02_10:2013-07-02, 2013-07-02, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307020174
Cc: 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 20:02:01 -0000

--
Regards,
Uri         <uri@ll.mit.edu>
<Disclaimer>

On Jul 2, 2013, at 14:55 , Yoav Nir wrote:
> On Jul 2, 2013, at 7:12 PM, Paul Hoffman <paul.hoffman@vpnc.org>
> wrote:
> 
>> On Jul 2, 2013, at 8:51 AM, Yoav Nir <ynir@checkpoint.com> wrote:
>> 
>>> "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.
>> 
>> So you are proposing Camellia as a SHOULD for IPsec instead of TripleDES? (Yes, I'm holding your feet to the fire here.)
> 
> Yes. The algorithms we've heard about are GOST, SEED, and Camellia. All others are too obscure, including the old AES competition contenders. GOST uses a 64-bit block, and of the other two Camellia gets more use because of OpenSSL and Firefox.

If it has to be one of these three - Camellia would be the best candidate.

> I would prefer that the line about DES would be gone completely.

Concur.

>>>>> - 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.
>> 
>> And saying so in the document would be valuable.
> 
> I'm still looking for the rationale for SHOULD, let alone SHOULD+ for it.

With AE modes there is no rationale to use separate encryption and authentication that I can think of.  The rationale of using GMAC instead of HMAC-SHA* is: (a) better performance, and (b) security proofs make better (to my taste) assumptions. These two should be sufficient.