Documentation for AES-GCM should discourage AES-192 and encourage nonce size 96 (12 bytes)

[jonasfj]

Documentation for AES-GCM should discourage AES-192 and encourage nonce size 96 (12 bytes).

This follows documentation from BoringSSL:
https://boringssl.googlesource.com/boringssl/+/HEAD/include/openssl/aead.h?pli=1

I don't think we should make these recommendations without appropriate sources.
Meaning we should like to somewhere reputable that backs up claims that aes-192 and aes-gcm nonce size other than 96 bits is bad and should be avoided for use-cases other than interoperability.

There is also some discussions in the following BoringSSL bug:
https://bugs.chromium.org/p/boringssl/issues/detail?id=34
Which in turn references:
https://eprint.iacr.org/2012/438.pdf
Which looks like it's written in LaTeX so it must be the truth 🤣
Okay, maybe we have to evaluate the credibility a bit, but it could be a credible source.

---

I don't think we should consider disabling AES-192 or AES-GCM with nonce size other than 96 bits.
If these are supported by BoringSSL and most browsers, then I think we should keep them.
They may be useful / necessary for interoperability with existing systems.

But it seems reasonable to update our documentation to clearly state:

• We do discourage using nonce sizes other than 96 bits (unless for interoperability with existing sytems), and
• The reason we discourage this is , for details see: .

While we're at it, it's very plausible that the AES-192 recommendation applies to AES in all other block modes too. Again, we need sources.
And it might be worth investigating if we can find similar recommendations (with sources) for nonces, counters, etc for other primitives or AES blockmodes.

[sigurdm]

https://crypto.stackexchange.com/questions/41601/aes-gcm-recommended-iv-size-why-12-bytes has some discussion. Not sure I follow all the arguments.