17.1 TLS Record protocol

The purpose of the TLS Record protocol is to cryptographically protect data in transit using the shared secret keys that Alice and Bob established using the TLS Handshake protocol. More precisely, the Record protocol takes a message that Alice wants to send, partitions the message into one or multiple blocks, protects these records by cryptographic means, and transmits the protected records. When Bob receives this information, the Record protocol ensures that the records are verified regarding their authenticity and integrity, decrypted using the correct key, and reassembled into the original message sent by Alice.

Every TLS record has one of the following four types:

• handshake
• application_data
• alert
• change˙cipher˙spec

Having types is beneficial because this way multiple higher-level protocols can use the same record layer. If Alice or Bob receive an unexpected record type, they terminate their TLS session and transmit the unexpected˙message alert.

The change˙cipher˙spec is a bit of an exception. If Alice or Bob receive an unencrypted TLS record having change˙cipher˙spec as type and containing the value 0x01 between the first ClientHello and the peer’s Finished messages, they simply drop this change˙cipher˙spec record. Otherwise, if the value is different from 0x01 or that record is received before the first ClientHello or after the peer’s Finished messages, the receiving party — either Alice or Bob — terminates the TLS connection with the unexpected˙message alert.

17.2 TLS record layer

The TLS record layer partitions data to be transmitted into TLSPlaintext records of up to 214 bytes. The data structure of a TLS 1.3 TLSPlaintext record is shown in Listing 17.1.

Listing 17.1: Structure of TLSPlaintext records

enum {
   invalid(0),
   change_cipher_spec(20),
   alert(21),
   handshake(22),
   application_data(23),
   (255)
} ContentType;

struct {
   ContentType type;
   ProtocolVersion legacy_record_version;
   uint16 length;
   opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

The legacy˙record˙version variable denotes the record’s TLS version. As of TLS 1.3, legacy˙record˙version is deprecated, and the only requirement in the TLS 1.3 specification is for this field to have the value 0x0303 for all records, except the initial ClientHello, which may also have the value 0x0301 for compatibility reasons.

To maximize backward compatibility, the record carrying Bob’s first ClientHello preferably has version 0x0301, which stands for TLS 1.0. The record carrying Bob’s second ClientHello or Alice’s ServerHello has version 0x0303, which stands for TLS 1.2.

The data being sent is stored in the fragment variable. TLS treats the fragment value as opaque because this data is interpreted and processed by a higher-level protocol specified in the type variable of TLSPlaintext.

The length variable contains the size of the record’s fragment in bytes. Recall that the maximum size of a TLS 1.3 record is 214 bytes. If Alice or Bob receive a TLS record exceeding this size, they terminate the TLS connection and send a record˙overflow alert.

The type variable contains the high-level protocol that is used to process the fragment contained in the record. Valid protocols are listed in the enumeration ContentType. The TLS record layer handles message boundaries based on their ContentType:

• handshake messages can be put into a single TLSPlaintext record or distributed over several records. However, if a handshake message is distributed over several records, no other records are allowed between them. Moreover, handshake messages are not allowed to span key changes. That is, handshake messages that immediately precede a key change must align with the record boundary. Otherwise, the connection is terminated with the unexpected˙message alert.
• Messages of type application˙data can be distributed over several TLSPlaintext records or combined into a single record. Unlike with handshake messages, application data is opaque to TLS and zero-length fragments can be transmitted for application˙data to protect a TLS session against traffic analysis.
• alert messages must be put into a single TLSPlaintext record, and multiple alert messages must be distributed over multiple records. That is, a TLSPlaintext record of type alert contains exactly one message.

So far, we have discussed the structure of the TLS record layer. We now turn to the original purpose of the record layer, namely to protect its payload.