On Tue, 7 Jun 2022, Daniel Migault wrote:
What will it take to add AES-GCM-12 to supported ciphers by IKE (and thus ESP)? For my use case, I have a hard time seeing why I need a 16-byte ICV. Even an 30 min operation with streaming video is a limited number of packets.
I think we do not enable compression of the signature as the security implications are too hard to catch. When an reduced ICV is needed, there is a need to define the transform. In your case rfc4106 seems to address your concern with a 12 and even 8 byte ICV.
The authors of RFC 4106 really did not want to have the different versions with different ICVs but were pressured into it. That is why RFC 8221 and RFC 8247 basically say: As the advantage of the shorter (and weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet ICVs remain at the MAY level. I don't think people saw the packet counter as fundamental in this. I think mostly the strenth of the ICV length itself mattered. Also, since I think Robert cares about FIPS for this, CNSA only allows the 16 byte ICV, see RFC 9206: https://datatracker.ietf.org/doc/html/rfc9206#section-5 So I think it is best if you would stick to the 16 bytes ICV here :) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
