AES_GCM and TLS sequence number

Question

Am I right about that AEAD encryption/decryption uses a TLS sequence number twice, first time in the nonce and a second in additional data?

And why did they make the TLS 1.2 sequence number 2 times bigger than the TSP sequence number? Why does they need this overhead?

About additional data from rfc5246#page-25

The additional authenticated data, which we denote as additional_data, is defined as follows:

additional_data = seq_num + TLSCompressed.type +

                        TLSCompressed.version + TLSCompressed.length;

---

About nonce from rfc5288#page-2

        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.

Answer 1

The sequence number MAY be used twice.

First there is, indeed, the sequence number, which is the number of records sent since the last handshake. That value is what is used in the "additional data" for AEAD cipher suites (in CBC+HMAC cipher suites, the sequence number is part of the input to the HMAC).

Then there is also the per-record IV, which must have length 12 bytes; in TLS 1.2, these 12 bytes are the concatenation of an implicit 4-byte value (the one computed from the key exchange) and an explicit per-record 8-byte field. The sender is responsible for choosing that 8-byte value, with the caveat that any given value MUST NOT be reused (with the same key). However, GCM is not picky about that IV, as long as the "no reuse" rule is respected. Thus, many implementations find it expedient to use a simple counter, and the consequence is that the counter will be synchronized with the sequence number, since both will be incremented for each outgoing record. This is not a problem.

TLS 1.2 could have been defined to use the sequence number directly for the GCM per-record IV; this would have saved 8 bytes in each record. It would have been fine. The saving is not big, though: you want to save bytes when you send a lot of data, and then you are probably using big records (16384 bytes of plaintext per record), so 8 extra bytes are not comparatively a big deal.

Why TLS 1.2 was defined that way is a bit unclear; one would have to dig through the minutes of committee meetings to see if there was some reason for that. It is a rather safe bet, though, that if there was a "reason", then it probably was a vague semi-dogmatic assertion like "we must include an explicit field because it may help counter a future unknown attack in some as yet unspecified way".