Subject: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Feb 2015 13:21:29 +0200

Hi

A little over a year ago I proposed to define the ChaCha20 cipher and Poly1305 authenticators for IKE and IPsec both as standalone documents and as an AEAD. At the same time Adam Langley proposed the same to the TLS working group.

We were told two things: First, the groups preferred only the AEAD, and second, we were requested to get CFRG’s stamp of approval.

This resulted in a CFRG document defining the algorithms, and offering implementation advice and test vectors. This document has just been approved and has been sent to the RFC editor [1].

In the meantime, I have updated my draft to only define the AEAD. Since we not have CFRG’s “stamp of approval” if not yet an RFC number, I would like to renew my request to have the ChaCha20+Poly1305 for IKE and IPsec document [2] accepted by this working group with the intent of having it published as a standard-track document.

Thanks

Yoav

[1] https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/history/ <https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/history/>
[2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05 <https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Feb 2015 15:26:36 +0200

> On Feb 24, 2015, at 1:21 PM, Yoav Nir <[email-masked]> wrote:
> 
> In the meantime, I have updated my draft to only define the AEAD. Since we not have CFRG’s “stamp of approval” …

* Since we **now** have...

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Feb 2015 09:24:18 -0500

Yoav Nir <[email-masked]> wrote:
    >> In the meantime, I have updated my draft to only define the
    >> AEAD. Since we now have CFRG’s “stamp of approval” …

I needed to read up on these things, and I read:
  ChaCha20+Poly1305 can be as much as 300% faster than AES-256-GCM with SHA-1
  authentication.

and claims that Poly1305 is faster than SHA1/2/3.
This is certainly interesting to me.

{I'm very concerned in the IoT space (not really IPsec related at all), that
we are cooking too much AES-GCM in as the one and only choice, and may lose
algorithm agility in protocols.}

I am supportive of defining code points for these.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Feb 2015 16:49:05 +0200

> On Feb 24, 2015, at 4:24 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I’m guessing you mean AES-256-CBC, because if you use GCM, you don’t need SHA-1. Either way, these values are right for older Intel chips as well as ARM and whatever is it that runs in the IoT space. Newer Intel chips with the AESENC opcode have faster AES-GCM than ChaCha20+Poly1305.

> algorithm agility in protocols.}

Interesting. I thought they were baking AES-CCM into IoT standards. ChaCha20+Poly1305 are attractive options because of a very small code base, and a 64-byte workspace for ChaCha (16 x 32-bit ints). Can’t get below ~500 bytes for AES.

Thanks

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Feb 2015 17:46:57 +0200

Yoav Nir writes:
> Interesting. I thought they were baking AES-CCM into IoT standards.
> ChaCha20+Poly1305 are attractive options because of a very small
> code base, and a 64-byte workspace for ChaCha (16 x 32-bit ints).
> Can’t get below ~500 bytes for AES. 

IEEE 802.15.4 has AES-CCM* in the MAC, and there is no algorithm
agility there at all, i.e. no other ciphers are possible. There is
possibility to message authentication only, or both message
authentication and encryption, and there is possibility to do it with
either 32, 64, or 128 bit MIC (message integrity code) lengths.

Other radio interfaces might of course use something else, and upper
layers running over IEEE 802.15.4 or similar might use their own
security methods. In the 802.15.4 chipsets there is quite often AES
hardware accelerator that can do the AES modes needed for AES-CCM, and
because of that the upper layers might also want to use AES-CCM
instead of ChaCha20+Poly1305.

Anyways I think adding ChaCha20+Poly1305 to algorithms usable in IPsec
is good thing, and I support this work.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Feb 2015 09:48:07 -0500 (EST)

On Tue, 24 Feb 2015, Yoav Nir wrote:

> In the meantime, I have updated my draft to only define the AEAD. Since we not have CFRG’s “stamp of approval” if not yet an RFC number,
> I would like to renew my request to have the ChaCha20+Poly1305 for IKE and IPsec document [2] accepted by this working group with the
> intent of having it published as a standard-track document.

I am in favour of adopting this document for the WG.

> [2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05

Can we rename ESP_ChaCha20-Poly1305 to ESP_ChaCha20_Poly1305 ? That
allows implementors to match the literal IANA string into C-code, which
does not allow a "-" symbol.

 	The problem is that if future advances in cryptanalysis reveal a
 	weakness in AES, VPN users will be in an unenviable position.  With
 	the only other widely supported cipher being the much slower 3DES,

I'm not sure if that is completely true. We do have Camellia, although
I'm not a cryptographer and it might be too similar to AES. So I still
agree with the sentiment of the text.

 	The length of the ciphertext as a 32-bit network order quantity.

Can we clarify the number of octets used here without needing to go into
another reference document?

I kind of dislike using HMAC-SHA-256 but I understand we don't have much
choice right now:

https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10#section-2.7

Although perhaps we can go back to CRFG and ask if they can give us
something that is not based on the SHA2 family?

I have no strong opinions about Diffie-Hellman groups.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Fri, 27 Feb 2015 00:37:55 +0200

> On Feb 26, 2015, at 4:48 PM, Paul Wouters <[email-masked]> wrote:
> 

Hmm, it’s like version -10 all over again:
http://www.ietf.org/rfcdiff?url1=draft-irtf-cfrg-chacha20-poly1305-09&url2=draft-irtf-cfrg-chacha20-poly1305-10

> agree with the sentiment of the text.

There are several algorithms that exist, and even quite a few that are defined for IPsec. But none are as universally implemented as 3DES and AES. So as a developer I can implement Camellia (and I have no idea about its speed relative to AES), but as a user with an existing version of some software that has to interoperate with some other user of some other version of some other software, only with AES and 3DES it’s safe to assume that we can achieve interoperability.

> another reference document?

Mmm, 4?   Network order is the controversial part, because everything else in ChaCha20 is little-endian.

> I kind of dislike using HMAC-SHA-256 but I understand we don't have much

For PRF? What’s wrong with HMAC-SHA-256?  I would have preferred to use these algorithms for the PRF. Poly1305 is not suitable as a PRF. ChaCha20 is a block cipher in counter mode and is very suitable as a PRF, but it doesn’t fit the definition of a PRF in section 2.13 of RFC 7296.

> something that is not based on the SHA2 family?

Why don’t you like SHA2?  Is it about the performance or just a general dislike of NIST algorithms?
Anyway, perhaps you’d like blake2 better:
http://tools.ietf.org/html/draft-saarinen-blake2-01

Still seems like a shame to brink that in just for the PRF.

> I have no strong opinions about Diffie-Hellman groups.

Perhaps Curve25519 after CFRG finish recommending it.

Yoav