18

TLS Cipher Suites

In the previous chapter, we revisited the TLS Record protocol from a higher-level perspective to understand how the individual cryptographic mechanisms – block ciphers, AEAD, and, in particular, the Galois counter mode – fit together to ensure confidentiality and integrity of data transmitted in TLS records.

In this chapter, we will cover TLS 1.3 cipher suites: combinations of ciphers and cryptographic algorithms that any TLS 1.3 endpoint must support and implement. In terms of RFC 8446 material, we will mainly cover the following:

• Subsection 9.1, Mandatory-to-Implement Cipher Suites

• Appendix B.4, Cipher Suites

In addition, we will introduce two additional cryptographic algorithms – ChaCha20 and Poly-1305 – that can be used in TLS 1.3 and which we have not covered so far.

Upon completion of the chapter, you will have a comprehensive overview of combinations of cryptographic algorithms allowed by the TLS 1.3 standard. More precisely, you...

18.1 Symmetric cipher suites in TLS 1.3

TLS 1.3 specifies a set of so-called symmetric cipher suites that Alice and Bob can use to protect the data transmitted via the TLS Record protocol. Each symmetric cipher suite is a pair composed of two cryptographic algorithms:

• An AEAD algorithm used for protecting the confidentiality and integrity of TLS records

• A hash algorithm used within the HKDF function to derive TLS secrets and shared keys

The name of a TLS symmetric cipher suite starts with the string TLS and has the following format:

TLS_<AEAD algorithm>_<Hash algorithm>

where ¡AEAD algorithm and ¡Hash algorithm¿ are placeholders for specific algorithms. In addition, every cipher suite has a unique 2-byte identification value associated with it.

Table 18.1 shows the symmetric cipher suites that Alice and Bob can use according to the TLS 1.3 standard.

...

Cipher suite	2-byte identifier
TLS˙AES˙128˙GCM˙SHA256	0x13,0x01

18.2 Long-term security

In his famous book The Cathedral and the Bazaar [144], the American software developer and open-source advocate Eric Raymond coined the phrase that ”given enough eyeballs, all bugs are shallow”. Raymond used the phrase – which later became known as the Linus Law in honor of Linus Torvalds – to highlight the benefits of the open-source development model, where the peer review conducted by a large developer community is very effective in identifying and fixing software bugs.

As discussed in Chapter 14, Block Ciphers and Their Modes of Operation, the AES algorithm was chosen in a worldwide public contest where the entire cryptographic community was able to submit their own proposals and find cryptographic flaws and weaknesses in others. The candidates’ algorithms were scrutinized by dozens of world-class cryptographers and leading experts in their respective sub-fields, and this type of contest for selecting cryptographic...

18.3 ChaCha20

ChaCha20 is a fast block cipher defined in RFC 8439 ChaCha20 and Poly1305 for IETF Protocols [131]. The number 20 in the cipher’s name refers to a specific ChaCha variant that uses 20 rounds or, equivalently, 80 quarter rounds to compute the ciphertext.

ChaCha20’s state is stored in a 4 by 4 matrix consisting of 32-bit unsigned integers. The state representation using a matrix explains why some ChaCha rounds are referred to as column rounds while others are referred to as diagonal rounds:

0   1   2   3
4   5   6   7
8   9  10  11
12  13  14  15

18.3.1 ChaCha20 quarter round

The ChaCha20 algorithm’s basic operation is the so-called quarter round. The quarter round operates on four elements of the ChaCha20 state, hence the name. The four elements are denoted as a, b, c, and d and the quarter round is defined as:

where ≪ n denotes the rotate left by n bits operation, for example:

The ChaCha20 quarter round is illustrated in Figure&...

18.4 Poly1305

Poly1305 is a message authentication code specified in RFC 8439 [131]. It takes a 256-bit one-time key k and an arbitrary length plaintext m, and produces a 128-bit tag used to authenticate message m.

The key k is partitioned into two parts, which RFC 8439 refers to as r and s. The pair (r,s) must be unique and unpredictable for each Poly1305 invocation. The 16-byte part r may be constant, but must undergo the following modification, referred to as clamping in RFC 8439:

• The four highest bits of bytes 3, 7, 11, and 15 must be set to 0 (in other words, these bytes must be smaller than 16).

• The two bottom bits of bytes 4, 8, and 12 must be set to 0 (in other words, these bytes must be divisible by 4).

Part s, the other 16-byte part of the secret key k, must be unpredictable. However, r and s can also be (pseudo)randomly generated for each new Poly1305 invocation.

Poly1305 pseudocode is shown in Algorithm 9. It takes a 256-bit one-time key and an arbitrary-size message...

18.5 ChaCha20-Poly1305 AEAD construction

ChaCha20-Poly1305 is a cryptographic algorithm for authenticated encryption with additional data (AEAD, see Chapter 15, Authenticated Encryption). Like the two building blocks ChaCha20 and Poly1305, ChaCha20-Poly1305 used in TLS is defined in RFC 8439 [131]. Initially, both building blocks were proposed by the American cryptographer Dan Bernstein [25, 23].

The ChaCha20-Poly1305 AEAD construction is illustrated in Figure 18.3. As you can see, the algorithm takes four inputs:

• A 256-bit shared secret key k

• A 96-bit nonce n, which must be different for each ChaCha20-Poly1305 algorithm invocation with the same key

• A plaintext p of arbitrary size

• Arbitrary-sized additional authenticated data d

In the first step, the Poly1305 one-time key k_ot is generated using the ChaCha20 block function B as described in Algorithm 10.

In the second step, the ChaCha20 encryption process C, discussed previously in this chapter and illustrated...

18.6 Mandatory-to-implement cipher suites

For compatibility purposes, every TLS endpoint must fulfill a minimum set of requirements. To ensure this, Chapter 9 in RFC 8446 defines three types of compliance requirements:

1. Mandatory-to-implement cipher suites

2. Mandatory-to-implement TLS extensions

3. Protocol invariants that every TLS endpoint and middlebox must follow

If there is no dedicated application profile standard that prescribes different algorithms, TLS 1.3 specification requires a TLS endpoint to implement cipher suites given in Table 18.2. Note, however, the difference in the requirement level for the specific cipher suites. The exact meaning of the capital words MUST and SHOULD is defined in IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels.

The term MUST (or its equivalents, REQUIRED or SHALL) means that the requirement is absolutely mandatory – there is no room for exceptions. In contrast, the term SHOULD (or its equivalent, RECOMMENDED...

18.7 Summary

In this chapter, we discussed the TLS 1.3 cipher suites, including those that every TLS endpoint must implement. We covered the alternative cipher suite ChaCha20-Poly1305 as well as its building blocks, ChaCha20 block cipher, and Poly1305 message authentication code.

On a more fundamental level, to aid in-depth understanding of TLS cryptography, we discussed how advances in cryptanalysis can affect long-term security, how this risk can be mitigated using cryptographic agility, and how the concept of a standby cipher implements this pattern in TLS 1.3.

This chapter concludes the third part of the book. In the next part, we will change the perspective and look at TLS in general, and TLS 1.3 in particular, from an attacker’s point of view. We will first cover attacks on cryptographic schemes and cryptographic protocols from a conceptual, theoretical perspective.