Zero round-trip time mode 2 – Transport Layer Security at a Glance

Here, key agreement is based on ECDHE, and the public keys are authenticated by means of RSA. The fact that these identifiers are missing in TLS 1.3 cipher suites does not mean there are no options in this area anymore. In the refsubsec:TLSV13Handshake handshake protocol section, we have seen there is still the choice between using PSKs, Diffie-Hellman based on finite fields, or ECDHE. However, these options are not negotiated by means of the cipher suites anymore, but by the form of the key shares offered by the client and server during handshake.

The remaining symmetric encryption algorithms in the cipher suites all support Authenticated Encryption with Associated Data (AEAD), a modern and particularly secure encryption mode that combines confidentiality, data integrity, and message authentication in a single cryptographic scheme. We cover AEAD in more depth in Chapter 15, Authenticated Encryption. This is yet another example of an established cryptographic scheme such as the CBC mode of operation for block ciphers eventually becoming legacy and being replaced by newer, more secure alternatives.

Static Diffie-Hellman and RSA-based protocols for key transport were removed. As a result, every key exchange mechanism based on public-key cryptography guarantees forward secrecy in TLS 1.3. Forward secrecy is a highly desirable feature for any cryptographic protocol because it ensures post-compromise security. Even if Eve manages to break one TLS session, she needs to invest the same amount of computational work to break any previous session. This is also true if Eve manages to get hold of Alice’s private key. Even with respect to future sessions, knowledge of a private key does not bring her any advantage, if she remains a purely passive attacker. As an active attacker, however, she will be able to impersonate Alice and thereby break any future sessions.

In addition, all handshake messages after ServerHello are encrypted in TLS 1.3. This is another example of further increasing the protocol’s security by offering as small an attack surface to Eve as possible, especially considering that in the future Eve might discover attacks that are not known today.

KDFs used in TLS 1.3 have been redesigned to allow easier security analysis by cryptographers. This nicely illustrates how simplicity facilitates security. If a cryptographic protocol, mechanism, or primitive is simpler, it can be easier understood. As a result, it is more likely that any security flaws will be spotted by cryptographers. The corollary of this is that complex cryptographic mechanisms must be trusted less.

Finally, changes to the handshake state machine and the introduction of a single new PSK exchange made the protocol simpler. Improvements were also made to reduce the number of round trips during the handshake phase during the initial TLS session.

6.8 Summary

In this chapter, we looked into the motivation behind TLS, how it evolved to address the security needs of the WWW, and how it works from a 10,000-feet perspective.

In the course of this high-altitude overview, we introduced the TLS subprotocols, especially the handshake protocol and the record protocol, and looked into TLS 1.3 and 1.2 handshakes in somewhat more detail. Finally, we saw several examples of cryptographic good practices introduced in TLS 1.3. However, the ultimate reasons for some of the design choices in TLS 1.3 will only become clear once we look at some of the earlier attacks on TLS in Part IV, Bleeding Hearts and Biting Poodles.

This chapter also finishes the Getting Started part of this book. In the next part, Shaking Hands, we will cover the TLS handshake protocol and its underlying cryptographic building blocks in detail, and explain how and why they work to allow Alice and Bob to securely communicate with each other.