TLS 1.3 is finished, and we have already shipped it

RFC 8446 was published on 10 August, ending four years and twenty-eight drafts. We had been running a draft version on the gateway since the spring and switched to the final version last week.

One round trip

The handshake is the headline. TLS 1.2 needs two round trips before any application data moves; 1.3 needs one. On a connection from Lagos to Frankfurt, that is roughly a hundred milliseconds removed from every new connection, before we have done any work.

For a client that holds a connection open, this matters once. For serverless callers that reconnect constantly — an increasingly large share of our traffic — it matters on every invocation, and those are exactly the clients most sensitive to cold latency.

The shorter list of mistakes

The more valuable change is subtraction. RSA key exchange is gone, so a compromised server key can no longer decrypt recorded traffic from the past. Static Diffie-Hellman is gone. CBC mode ciphers are gone, and with them a decade of padding oracle attacks. Compression is gone, and with it CRIME. Renegotiation is gone.

The set of cipher suites went from hundreds of combinations, most of them bad, to five. It is now genuinely difficult to configure TLS 1.3 insecurely, which is not something anyone could say about 1.2.

What we did not turn on

0-RTT resumption lets a client send application data in its first packet, which is fast and replayable. An attacker who captures that packet can send it again. That is acceptable for an idempotent GET and dangerous for anything that charges money or changes state.

We have left it off. If we enable it later it will be for specifically marked idempotent endpoints, with replay windows, and never for the whole gateway.

What you need to do

Nothing. Negotiation is automatic and TLS 1.2 clients are unaffected. We will start talking about deprecating 1.0 and 1.1 next year, and that will come with a long notice period.