Should you delay TLS 1.3 because old clients can't handle it?

Should you delay TLS 1.3 because old clients can't handle it?

A recurring piece of conservative advice — "keep TLS 1.2 only, 1.3 breaks legacy clients" — misunderstands how version negotiation works. TLS 1.3 (RFC 8446) was deliberately engineered for coexistence. A 1.3-capable server still completes a 1.2 handshake with a 1.2-only client; the version is negotiated per connection via the supported_versions extension. Enabling 1.3 does not remove 1.2.

The genuine compatibility problem was the reverse: middleboxes. Early 1.3 drafts failed against intrusive proxies that assumed the 1.2 record format. The IETF's response was "middlebox compatibility mode" (RFC 8446, Appendix D.4), which disguises the handshake to look like a 1.2 resumption — dummy ChangeCipherSpec records, a non-empty session ID. Langley and others measured this during the draft-23 deployment that fixed the breakage.

So refusing to enable 1.3 forgoes its real gains — one round-trip handshake, removal of RSA key transport and static DH, mandatory forward secrecy — to solve a problem the protocol already solved.

— 1.3 and 1.2 negotiate per connection
— Compatibility mode neutralized middlebox breakage
— No legacy client is locked out by enabling 1.3

Further reading: RFC 8446, §4.2.1 and Appendix D.
Bottom line: Enable TLS 1.3 alongside 1.2. Negotiation handles the rest; there is no legacy penalty.