This month the IETF has published RFC 8446, the specification of TLS 1.3: it brings the full handshake down from two round-trips to one and makes forward secrecy a non-negotiable property of the connection. The document, edited by Eric Rescorla, closes a TLS Working Group effort that began in 2014 and reached publication after twenty-eight drafts.

Context

Earlier versions of the protocol carried a decade of vulnerabilities that struck constructions held to be sound at the time they were specified: BEAST (2011) and Lucky Thirteen (2013) against CBC-mode ciphers, CRIME (2012) against TLS compression, FREAK and Logjam (2015) against export cipher suites and weak Diffie-Hellman parameters, DROWN (2016) against the interaction with SSLv2 still enabled on the same hosts, ROBOT (2017) against RSA PKCS#1 v1.5 padding. Almost all of these attacks share a thread that is not an isolated implementation bug: it is the presence, in the standard itself, of fragile constructions that implementations had to keep anyway for interoperability.

TLS 1.2 (RFC 5246, 2008) pushed onto the deployment the choice of a safe configuration among many possible combinations, several of them insecure. A cipher suite such as TLS_RSA_WITH_AES_128_CBC_SHA stays valid under the standard while using RSA key exchange with no forward secrecy and a CBC cipher with MAC-then-encrypt. The configuration surface was itself the problem.

What the specification takes out

RFC 8446 removes from the standard — not merely from deployment guidance — a set of constructions:

  • static RSA and static Diffie-Hellman key exchange, with no forward secrecy;
  • all CBC-mode and MAC-then-encrypt ciphers;
  • RC4, 3DES, MD5 and SHA-1 as negotiable primitives;
  • TLS-level compression;
  • renegotiation and semantically meaningful ChangeCipherSpec (kept only as a compatibility byte for intermediaries);
  • “export” cipher suites and server-supplied Diffie-Hellman groups with arbitrary parameters.

It follows that every cipher suite the specification admits uses an ephemeral key exchange (ECDHE or DHE) and an AEAD cipher. The cipher-suite space drops from several dozen entries to five registered ones, three of them mandatory to implement: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. In the 1.3 naming the suite identifies only the AEAD cipher and the hash; key exchange and signature scheme are negotiated separately.

Handshake architecture

The difference shows in the first pair of messages. In TLS 1.2 the client sends ClientHello, gets the server’s choice with its parameters, then completes the key exchange in a second round-trip: two round-trips before any application data can flow. In TLS 1.3 the ClientHello already carries, in the key_share extension, the ECDHE public keys for the groups the client assumes the server will accept. If the guess is right, the server replies with ServerHello, its own key_share, and from there the rest of the handshake — certificate, CertificateVerify, Finished — travels already encrypted. The client closes with its own Finished and may send application data: one round-trip.

If the client gets the group wrong, the server replies with a HelloRetryRequest asking for a key_share over an acceptable group, and the handshake falls back to two round-trips. Hence the weight of the order in which the client offers its groups.

Everything after ServerHello is encrypted under keys derived from the handshake secret. The server certificate, which in TLS 1.2 went over the wire in the clear, is in 1.3 no longer visible to a passive intermediary. Keys are derived with HKDF (RFC 5869) through a staged schedule that keeps handshake secrets separate from application-traffic secrets.

Critical point: 0-RTT and replay

A client that has already established a session can, in TLS 1.3, send application data in the first packet of a new connection, before the handshake completes, using a pre-shared key derived from the previous session. This is the so-called 0-RTT.

The specification says plainly that 0-RTT data does not carry the same guarantees as the rest of the connection: it has no forward secrecy with respect to the PSK and, above all, it is exposed to replay. An attacker who captures the first flight can retransmit it, and the server, within the protocol, has no general mechanism to recognise it as a duplicate. Section 8 of the RFC goes into countermeasures — single-use tickets, narrow time windows — but none is complete, and restricting 0-RTT to idempotent requests stays a job for the application. In practice: no state-changing POST in the first flight. You enable it knowing what you are conceding, and not as a default everywhere.

Operational implications

For people running servers the upgrade depends on the underlying TLS library more than on the web server. OpenSSL has folded TLS 1.3 into the 1.1.1 branch, expected shortly as the first long-term-support release with the protocol enabled; nginx and Apache httpd inherit it once rebuilt or upgraded against that branch. NSS already has it in recent Firefox versions, and BoringSSL carries it into Chrome. On the server side enabling it is usually a configuration line, but the long tail sits in the chain of intermediaries: some middleboxes that inspect TLS traffic break 1.3 connections because they do not recognise the new message structure, which is why the handshake keeps dummy fields and ChangeCipherSpec that make it look like 1.2 on the wire.

Observability changes too. With the certificate encrypted and contents already protected after ServerHello, tools that drew information from cleartext handshake traffic now see less. The Server Name Indication in the ClientHello stays in the clear: the requested host is still readable by a passive observer, and encrypting that field is separate work, still at draft stage in the IETF.

Limits

The specification does not touch the trust model founded on Certificate Authorities: certificate validation is what it always was, with Certificate Transparency (RFC 6962) as a supplement rather than a replacement. It introduces no quantum-resistant primitives — the exchange stays ECDHE over classical curves, and post-quantum standardisation is a process of its own, still open. It does not fix SNI exposure. And 0-RTT, as above, moves a security problem from the protocol to the application instead of removing it. What the publication does close is one precise category of risk: the insecure-but-conformant TLS configurations, which under 1.3 are no longer expressible.

Cover image: Sequence diagram of the full TLS 1.3 handshake: message exchange between client and server (ClientHello, ServerHello, Certificate,… — diagram by Fleshgrinder, public domain — https://commons.wikimedia.org/wiki/File:Full_TLS_1.3_Handshake.svg