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

David McGrew <> Wed, 03 July 2013 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B92911E8100 for <>; Wed, 3 Jul 2013 16:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id liNy9L1FR5mT for <>; Wed, 3 Jul 2013 16:50:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E2BA111E80FF for <>; Wed, 3 Jul 2013 16:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4203; q=dns/txt; s=iport; t=1372895443; x=1374105043; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=PfqRbzg+avOaEp9LPYfjZXSME1ssuIW12LEbZJX3TP4=; b=jPy8IluIcTYYdkcC4wDClVpGNnKV2W6pQWPBEd0Tb3zU0mvk067fTE72 CZX9V+Qva9MokN7xWVls+PbIm9IDK6MZe/roUpg4sCyrQaVaL+bYtWkgx IRq+uYhfHKI37hZusHWahs+TqqddrHKsg8ypaXvL4D9ah7KQCabFsMDfU A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="230769753"
Received: from ([]) by with ESMTP; 03 Jul 2013 23:50:42 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id r63Nofqp015098 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 23:50:41 GMT
Message-ID: <1372895441.3983.322.camel@darkstar>
From: David McGrew <>
To: Yoav Nir <>
Date: Wed, 03 Jul 2013 19:50:41 -0400
In-Reply-To: <>
References: <1372775511.3983.76.camel@darkstar> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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: Wed, 03 Jul 2013 23:50:58 -0000

Hi Yoav,

thanks for sharing your thoughts, more inline:

On Tue, 2013-07-02 at 15:18 +0000, Yoav Nir wrote:
> 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. 

this is a valid concern, but in my opinion, it is a long-term concern,
not a short-term one.   That is, we should think about AES alternatives,
but we likely have enough time that we can use an orderly process like
the one we described in  

> 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. 

So Triple-AES should be acceptable to everyone.  (Just joking!)

> 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.

So, I agree that thinking about alternatives is a reasonable use of our

As an aside, I feel like we have been forced into a situation where we
are focusing on block cipher designs (AES vs. Camellia vs. SEED ....)
which is quite out of touch with modern crypto design, where the focus
is on higher-level constructs like authenticated encryption.  For
instance, the current activity in crypto design competitions is the
CAESER authenticated encryption "contest":     

> - 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

This is a valid point.   It would be reasonable to strip out all of the
"MAY implement" algorithms.   The reason for including them in the draft
is the fact that RFC 4835 and its predecessors (on which this draft is
based) specified some MAY implement algorithms, and also we felt like it
would be good to describe the status of "demoted" algorithms like
AES-CTR [RFC3686] in the draft, since they were mentioned in the earlier
version.   I am fine with removing the MAYs, as long as it reflects the
consensus of the working group (I don't want to have to change it back
later if there is a chorus of objection ;-)

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

I don't think so.  

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

Yeah, and it looks even slower next to GMAC.

>  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.

Well, interoperability is one major consideration, but security and
efficiency are others.  My opinion: let's not take something that is
available, but is not needed, and turn it into a requirement.  Probably
others have an opinion, and this would be a topic for ipsecme.   


> Yoav