17.4 Per-record nonce

Alice and Bob keep a 64-bit sequence number for reading and writing TLS records. They increment this number every time they read or write a TLS record.

At the start of a TLS session and whenever the shared secret traffic key is changed, Alice and Bob set this number to zero. The first TLS record transmitted under that key has 0 as its sequence number.

In practice, TLS sequence numbers do not wrap because of their size: in most typical scenarios Alice and Bob exchange much less than 264 records. For the unlikely case where the sequence number must be wrapped, TLS 1.3 specification tells Alice and Bob to either change that secret traffic key or end their TLS connection.

AEAD algorithms specify the range of valid per-record nonce lengths. The record-specific nonce for an AEAD algorithm is constructed like this:

1. The 64-bit sequence number of the TLS record is encoded in the network byte order.
2. In the next step, the encoded number is padded with zeros to the left until it has the length of iv˙length.
3. Finally, the padded record sequence number is XORed with client˙write˙iv if Bob generates that nonce or with server˙write˙iv if Alice generates that nonce.

Alice and Bob use the resulting value as a per-record nonce. Recall that a nonce – shorthand for number only used once – is a (pseudo-) random number used to prevent Mallory from mounting replay attacks where she would record and, later, replay messages originally sent by Alice or Bob. Using nonces, Alice and Bob can add to each of their messages a number that may only be used once, thereby preventing replay attacks.

17.5 Record padding

The TLS 1.3 specification allows Alice and Bob to pad their TLS records by increasing TLSCiphertext’s size in order to hide the size of the actual data from Eve.

While this may seem odd at first because the data sent is encrypted, if Eve can determine the size of the encrypted data, she can perform traffic analysis. Traffic analysis is one of the oldest attacks on communication and refers to the process of intercepting and examining encrypted messages sent by Alice and Bob in order to deduce information from the size, frequency, or other observable attributes of the encrypted communication. In other words, with traffic analysis Eve can determine communication patterns such as who is talking to whom, how much, how often, and when. Very often, these patterns can be more valuable than the content of the communication itself.

Traffic analysis has its roots in military intelligence. More precisely, it’s a technique employed in the branch of signal intelligence used by the military since the beginning of the 20th century. Examples in the military context include the following scenarios:

• If Alice and Bob communicate frequently, the likelihood is high that they are planning something
• If Alice communicates frequently with Bob, and Bob then communicates with Trent, then the command chain Alice → Bob → Trent is very likely
• If Alice and Bob communicate shortly before or after event A, and Trent and Claire communicate shortly before or after event B, Eve can determine with high likelihood who is involved in which events

Another example where traffic analysis poses a threat is related to privacy. Let’s say Alice hosts a website with multiple pages and a specific page P contains a large picture that, when transmitted, must be fragmented into 10 TLS records. Assume that other pages have only text data and, as a result, fit into a single TLS record. Now, if Bob clicks on a link to one of Alice’s pages, Eve can easily determine whether Bob is accessing page P based solely on the size of the network traffic transmitted from Alice to Bob.

This example illustrates why traffic analysis can be a very powerful attack: Eve can infer secret information without ever breaking the cryptographic mechanisms used to protect it.

When Alice and Bob generate a TLSCiphertext record, they may pad it with additional bytes up to the maximum length of a record. The padding bytes are simply 0x0 bytes appended to the ContentType field before encryption.

In addition, Alice and Bob can generate application˙data type records containing TLSInnerPlaintext with an empty, that is, zero-length, content field. This allows Alice and Bob to generate plausible fake traffic as a countermeasure against traffic analysis. However, TLS 1.3 does not allow Alice and Bob to send handshake or alert type records with an empty content field. If one of them receives such a record, the receiving party terminates the TLS connection and sends an unexpected˙message alert.

Padding is automatically verified by the TLS record protocol. When the encrypted˙record field of the TLSCiphertext message is decrypted on the receiving end, the record protocol implementation scans this field from its last byte to its first byte until it finds a non-zero byte.