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

[Yoav Nir <[e-mail]>]

> On Feb 26, 2015, at 4:48 PM, Paul Wouters <[e-mail]> wrote:
> 
> 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.

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


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

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.

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

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
> choice right now:

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.

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

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