What does the TLS 1.2 client finished message contain?

Question

I am implementing TLS 1.2 and I'm stuck on the client finished message.

My question is: what is the size and structure of a clients finished message in TLS 1.2 when using the ECDHE_RSA_AES_128_GCM_SHA256 cipher suite.

I searched for this question and someone somewhere stated its size is 48 bytes; more specifically:

• 12 byte verify data
• 1 byte handshake type
• 3 byte verify data length
• and 32 byte MAC

Is that really correct?

I mean: according to RFC 5246 finished messages have {verify_data[verify_data_length]} and verify_data = PRF(master_secret, finished_label, hash(handshake_messages). Also, according to RFC 5246 section 5 PRF(secret, label, seed) = P_<hash>(secret, label+seed) and P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed). So, when I compute HMAC using SHA256 for verify_data its size is 32 byte.

As a result, I'm a bit confused in relation to the verify_data size and the finished message structure. Can anyone help me to understand this and/or maybe put me on the right track somehow?

Answer 1

rfc5246 7.4.9 defines verify_data as

     PRF(master_secret, finished_label, Hash(handshake_messages))
        [0..verify_data_length-1];

Note the second line; this effectively truncates the PRF output to verify_data_length octets. It goes on to say that verify_data size

depends on the cipher suite. Any cipher suite which does not explicitly specify verify_data_length has a verify_data_length equal to 12.

ECDHE_RSA_AES_128_GCM_SHA256 is defined in rfc 5289 which does not explicitly specify, so this default applies.

Second, someone somewhere is wrong. GCM and CCM ciphersuites do not have a HMAC on the (plaintext) record, although stream and 'block' (CBC) suites do; instead an authentication tag is added to the encrypted record by the AEAD process. Compare 6.2.3.3 to 6.2.3.1 and 6.2.3.2.

Answer 2

In the Finished Message FOR TLS, verify data is 12 byte long unless it is stated otherwise in the ciphersuite, so in your case it is 12 byte long. It is in the following handshake message form:

struct {
      HandshakeType msg_type;    /* handshake type */
      uint24 length;             /* bytes in message */
      select (HandshakeType) {
         ...
          case finished:            Finished;
      } body;
  } Handshake;

However, since the question turned out to be DTLS NOT TLS this is modified to

struct {
     HandshakeType msg_type;
     uint24 length;
     uint16 message_seq;                               // New field
     uint24 fragment_offset;                           // New field
     uint24 fragment_length;                           // New field
     select (HandshakeType) {
       ...
       case finished: Finished;
     } body;
   } Handshake;

Finished message is created using the PRF of the agreed cipher suite. After creating Handshake message you need to convert it to a TLSCipherText structure, in the form of

struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          select (SecurityParameters.cipher_type) {
              case stream: GenericStreamCipher;
              case block:  GenericBlockCipher;
              case aead:   GenericAEADCipher;
          } fragment;
      } TLSCiphertext;

but again DTLS is different

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 epoch;                                     // New field
    uint48 sequence_number;                           // New field
    uint16 length;
    select (CipherSpec.cipher_type) {
      case block:  GenericBlockCipher;
      case aead:   GenericAEADCipher;                 // New field [sic]
    } fragment;
  } DTLSCiphertext;

Here you are using ECDHE_RSA_AES_128_GCM_SHA256 which 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).

In this structure, the aead-ciphered result includes encryption output || authentication tag. So you have sent the authentication tag by concatenating it to encrypted message. In the case for finished message, encryption output and authentication tag are outputs of the encryption of Finished message.

At the end, expected finished message from server side for cipher suite ECDHE_RSA_AES_128_GCM_SHA256 should look like this for TLS:

16 --ContentType(hanshake)
03 03 --protocolVersion(tls 1.2)
00 28 -- message length(40)
  --finished message--
  00 00 00 00 00 00 00 00 --nonce_explicit. (8 byte) (this is write sequence number, for initial handshake this should be all zero)
  xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx -- encrypted finished message. (16 byte) (Note that finished message is of length 16(1 byte finished message type + 3 byte handshake message length + 12 byte verify_data) )
  yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy -- authentication tag. (16 byte) (this is also output of the encrption of finished message using AES-GCM)

but this for DTLS

16 -- type=handshake
fe fd -- version=DTLS1.2
nn nn -- epoch, 1 for the initial negotiation, more if renegotiation
00 00 00 00 00 00 -- seqnum, always zero because Finished is first after CCS
00 30 -- length=48
  (8 bytes) -- explicit nonce
  (24 bytes) -- encryption of Finished handshake message
  (16 bytes) -- authentication tag