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

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Tue, 02 July 2013 21:20 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 99A8F21F955A for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 14:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.035
X-Spam-Level:
X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 JNaIa0fl0euh for <cfrg@ietfa.amsl.com>; Tue, 2 Jul 2013 14:20:07 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6312921F9590 for <cfrg@irtf.org>; Tue, 2 Jul 2013 14:20:07 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r62LJw4E003993; Tue, 2 Jul 2013 17:19:58 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'ynir@checkpoint.com'" <ynir@checkpoint.com>
Date: Tue, 2 Jul 2013 17:19:58 -0400
Thread-Topic: [Cfrg] request for review of IPsec ESP and AH Usage Guidance
Thread-Index: AQHOdzDw7P3QbkGTeUKjeqgDY7zJtZlRTjUAgAAECACAAATkAIAABjgAgAAth4CAABJmAIAACFWAgAA/yf0=
In-Reply-To: <951F544D-382E-4743-955F-4C8F1880F443@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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-1307020195
Message-Id: <20130702212007.6312921F9590@ietfa.amsl.com>
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>, "'paul.hoffman@vpnc.org'" <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 21:20:12 -0000

But Yoav, my whole point was that:

- there is (almost) no reason to use AH now, as ESP handles _authetication-only_, encryption-only, encryption+authentication;

- for any use that involves encryption+authentication there is no justification (nor reason :) to use anything but one of AE encryption modes such as GCM (<b>no</b> reason to use AES-whatever plus HMAC-whatever); this includes a naïve attempt to do separate AES-CTR + AES-GMAC - just do AES-GCM instead;

- for any use that involves authentication-only (such as ESP-authenticate, or AH - doesn't matter) one SHOULD employ GMAC instead of HMAC, for reasons specified in the previous posting.

This reasoning (GMAC instead of HMAC) applies to ESP as much as to AH. 

P.S. IMHO the _only_ case when you might want to use AH at all is when you both need to authenticate a larger part of the IP header than ESP covers _and_ you want to use Transport rather than Tunnel mode of IPsec.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <uri@ll.mit.edu>;
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

 

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Tuesday, July 02, 2013 04:31 PM
To: Blumenthal, Uri - 0558 - MITLL
Cc: Paul Hoffman <paul.hoffman@vpnc.org>;; cfrg <cfrg@irtf.org>;
Subject: Re: [Cfrg] request for review of IPsec ESP and AH Usage Guidance


On Jul 2, 2013, at 11:01 PM, "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>; wrote:
> 
> 
>>>>>> - 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.

And I'm not objecting to it being a SHOULD with or without + for AH. I'm only asking about ESP.