Deploying TLS 1.3: the great, the good and the bad

Version 1.3 is the latest Transport Layer Security (TLS) protocol, which allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. TLS is the S in HTTPS. A lot has changed between 1.2 (2008) and 1.3. At the a high level, 1.3 saves a round-trip, making most connections much faster to establish. We'll see how the 1.2 handshake worked, and what had to change to enable 1-RTT handshakes. But even more importantly, the 1.3 design shifted towards putting robustness first. Anything that is not strictly necessary to the main function of TLS was removed (compression, renegotiation); choices of suboptimal security aren't offered at all (static RSA, CBC, RC4, SHA1, MD5); secure, easy to implement designs are introduced or privileged (RSA-PSS, AEAD implicit nonces, full handshake signatures, Curve25519, resumption forward secrecy). We will go into the why and how of all of these. But two major trade-offs had to be made: first, 1-RTT handshakes inherently prevent the introduction of encrypted domain names (SNI). We'll see why and what can replace them to provide similar privacy. Most interestingly, 1.3 comes with 0-RTT resumption. The catch there is that the protocol itself provides no complete protection against replay attacks. We'll unpack the problem, see what mitigations are available, what the risks and attacks are and how that requires careful API design and deployment. Finally, deployment hasn't been entirely smooth. Many servers out there turned out to be intolerant to 1.3 clients. We'll see what this causes, how it was worked around, and how downgrade protection provides defense in depth. TLS 1.3 is not in the distant future. The draft is almost finalized, and at Cloudflare we developed an open source stack in Go and support the protocol in beta for all websites. Chrome Canary and Firefox Nightly implement 1.3 clients.