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


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 of RFC 5246 talks about the associated data:

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

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.
  • $\begingroup$ 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? $\endgroup$
    – weaver
    May 31 '18 at 20:22
  • $\begingroup$ Note this is exactly the same pseudoheader added to the plaintext when computing HMAC for non-AEAD ciphersuites in, and its length 8+1+2+2=13 is the source of the RHUL group's 'Lucky 13' attack. $\endgroup$ Jun 1 '18 at 1:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.