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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
