Is there a TLS extension for generating unique IVs for AES GCM?

Question

Since reusing IVs is death for AES GCM, it seems like using the fixed IV in the TLS connection state is a phenomenally bad idea. It wouldn't even seem to be a good idea to use the salt + counter method since an attacker could watch for the first ciphertext record exchange and keep track from there. Is there an extension to address this? The RFC is distinctly unhelpful.

Answer 1

You can check this answer which mentions how does the IV generated for GCM ciphers in TLS 1.2

... is an AEAD Cipher, so it is in the form of GenericAEADCipher:

struct {
     opaque nonce_explicit[SecurityParameters.record_iv_length];
     aead-ciphered struct {
         opaque content[TLSCompressed.length];
     };
  } GenericAEADCipher;

Here, the nonce_explicit contains 8 byte nonce, and you combine this with the 'fixed IV' from key derivation (4 bytes) then you get 12 byte IV for AES-GCM mode encryption. (Note that you only sent the last 8 bytes of the IV).

Also, from the RFC 5288 (AES Galois Counter Mode (GCM) Cipher Suites for TLS)

6.1. Counter Reuse

AES-GCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse.

From Section 3 of the RFC 5288:

The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partially explicit" nonce; see Section 3.2.1 in [RFC5116]).

struct {
     opaque salt[4];
     opaque nonce_explicit[8];
} GCMNonce;

The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets.

The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets.

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

So, reusing the same IV in GCM ciphersuites in TLS is prevented in this way.