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) means that the requirement should be met by default, but there can be situations where the requirement may be ignored for particular reasons. More precisely, to put it in the exact words of RFC 2119, SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Table 18.2 shows the requirement levels of the three mandatory-to-implement cipher suites in TLS 1.3.

 Table 18.2: Mandatory-to-implement cipher suites in TLS 1.3

Similarly, if no application profile standard is given, TLS 1.3 requires every TLS endpoint to support digital signatures and curves given in Table 18.3. The exact meaning of the terms MUST and SHOULD defined in RFC 2119 applies here as well.

 Table 18.3: Mandatory-to-implement cipher suites in TLS 1.3

The small number of mandatory-to-implement cipher suites, signature algorithms, and curves greatly reduces the complexity of TLS 1.3 as opposed to earlier versions.

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.