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

From: David McGrew <[email-masked]>
Date: Tue, 02 Jul 2013 10:31:51 -0400

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,

David

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Jul 2013 15:18:41 +0000

> http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/?include_text=1

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jul 2013 08:33:10 -0700

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

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

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

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

Having the document list the rationale for using GMAC instead of an HMAC would indeed be good.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Jul 2013 15:51:55 +0000

> ...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) pic…

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

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

> 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

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 2 Jul 2013 11:57:46 -0400

On 7/2/13 11:33 , "Paul Hoffman" <[email-masked]> 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.

IMHO, at this point there's no alternative that is either necessary or
useful. Therefore I propose (c): leave this part alone and go on. If AES
does get broken - we'll have a bigger problem on our hands.

If patent issues aren't of concern - I would consider adding AES-*-OCB
mode as either SHOULD or at least MAY.

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

As you pointed out, we MAY implement anything. If you absolutely insist
that an algorithm or two MUST be mentioned in the MAY clause (:-), why not
one or two of the AES competition finalists (those that did not have any
attacks published)?

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

One reason to use AES-GMAC for ESP authentication is that ESP supports all
of the following: (a) don't encrypt but authenticate, (b) authenticate but
don't encrypt, (c) encrypt and authenticate. GMAC fits the (a) case
perfectly. In the past, people unfamiliar with how ESP and AH evolved, had
a misconception that when you need  authentication you use AH, when you
need encryption you use ESP, and when you need both you combine the two
(ESP+AH). IMHO it was mainly because of their ignorance of the main reason
behind creation of AH - the EXPORT CONTROL (of that time!) requirement for
an authentication-only mode that could not have encryption retrofitted in
in.

I see no reason to use GMAC (or any other MAC) over encrypted (e.g., with
AES-CBC) data: if you encrypt - there's no reason not to use AE/AEAD mode.
If you don't encrypt - use GMAC. When given a choice between GMAC and
HMAC-SHA256, the decision should be obvious (and not in favor of SHA :).

More detailed review to follow. :-)

TNX!

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jul 2013 09:12:56 -0700

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

So you are proposing Camellia as a SHOULD for IPsec instead of TripleDES? (Yes, I'm holding your feet to the fire here.)

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

Yes to all.

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

And saying so in the document would be valuable.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Jul 2013 18:55:53 +0000

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

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

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

> And saying so in the document would be valuable.

I'm still looking for the rationale for SHOULD, let alone SHOULD+ for it.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 2 Jul 2013 16:01:44 -0400

--
Regards,
Uri         <[email-masked]>
<Disclaimer>

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

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Jul 2013 20:31:34 +0000

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

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

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 2 Jul 2013 17:19:58 -0400

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: <[email-masked]>
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

---

From: David McGrew <[email-masked]>
Date: Wed, 03 Jul 2013 19:50:41 -0400

Hi Yoav,

thanks for sharing your thoughts, more inline:

On Tue, 2013-07-02 at 15:18 +0000, Yoav Nir wrote:
> - 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  
http://tools.ietf.org/html/draft-mcgrew-standby-cipher-00  

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

> least at the SHOULD level.

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

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":
http://competitions.cr.yp.to/caesar-call-3.html     

> anything: SEED, Camellia, GOST. That doesn't help with

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.   

David

---

From: David McGrew <[email-masked]>
Date: Fri, 05 Jul 2013 18:15:59 -0400

Hi Yoav,

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

The most important use of an authentication transform in ESP is with
NULL encryption, in which case GMAC is the clear winner because of
adequate security and exceptional performance.  

David