[zhuzhuor]

The second nit with AES-GCM is that, as integrated in TLS, implementations are free to use a random nonce value. However, the size of this nonce (8 bytes) is too small to safely support using this mode. Implementations that do so are at risk of a catastrophic nonce reuse after sending on the order of a terabyte of data on a single connection. This issue can be resolved by using a counter for the nonce but using random nonces is the most common practice at this time.

I don't know how do you integrate AES-GCM with TLS, but I have to say

1. The secure AES-GCM supports 96-bit nonces. It's 12 bytes, not 8 bytes mentioned in the article.

2. Nonce is nonce. It shouldn't be chosen at random (as random IVs). As long as nonces are not reused, GCM should be secure.

3. I don't believe implementing a secure random number generator is more efficient than maintaining an incremental counter.

Edited for typos

[agl]

> The secure AES-GCM supports 96-bit nonces

That's correct. However, TLS takes four bytes from the handshake key material and uses them as the first four bytes of the nonce. The remaining 8 bytes are all that vary over the lifetime of the connection.

[zhuzhuor]

Do you know why is TLS doing that?

But even without the 4 bytes, 64-bit nonce seems enough for me, as long as it's not chosen at random.

For comparison, if the nonce is chosen randomly, the security level is only 2^32 (supposing the 4 bytes based on the key materials remain unchanged).

[agl]

I believe it was done so that AES-GCM could be implemented in a FIPS module and would not need to depend on the uniqueness of provided nonces. Either that or some standard said that nonces must be unique. (I wasn't around for the discussion.)

I agree that a counter is perfectly safe.