# TLS 1.2 Cipher Suites With AES-GCM – What data (if any) is passed to the AES-GCM cipher as the Additional Authentication Data?

TLS 1.2 defines a number of cipher suites that employ AES-GCM, e.g.:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384


Being that AES-GCM is an AEAD cipher, it handles both encryption and integrity verification. Also, it can optionally accept additional authentication data as one of its inputs (in addition to the plaintext, the key, and the iv). The additional authentication data is not encrypted, but it is included in the integrity verification process.

I’ve read RFC 5289, RFC 5288, RFC 5246, etc., but I’ve not found any mention of what data, if any, is passed to the AES-GCM cipher as the additional authentication data in a TLS 1.2 implementation such as one of the above.

My question is: In a TLS 1.2 implementation that employs AES-GCM – what data (if any) is passed to the AES-GCM cipher as the additional authentication data?

Actually section 6.2.3.3 of RFC 5246 talks about the associated data:

The additional authenticated data, which we denote as

additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;


where "+" denotes concatenation.

So the sequence number, the packet version, the packet type and the packet length are passed as associated data to the cipher.

So why is exactly this data authenticated?

• The sequence number: Authenticating this helps prevent re-ordering and replay attacks and binds the sequence number to the data packet.
• The protocol version: Authenticating this ensures that if you can't downgrade the protocol version (eg to SSLv3) to exploit weaknesses and learn something about the content of the current packet.
• The packet type: I suppose this blocks you from re-using a handshake packet for an application traffic packet (which may have independent sequence number streams)
• The packet length: This blocks you from silently chopping some data off somewhere, but is mostly here because it's public data and authenticating it doesn't really hurt.
• Thank you for referencing this @SEJPM. What threat does this aim to prevent, and how does the use of this information as the additional authenticated data mitigate that threat? – weaver May 31 '18 at 20:22
• Note this is exactly the same pseudoheader added to the plaintext when computing HMAC for non-AEAD ciphersuites in 6.2.3.1, and its length 8+1+2+2=13 is the source of the RHUL group's 'Lucky 13' attack. – dave_thompson_085 Jun 1 '18 at 1:26