What TLS 1.3 Removed: Renegotiation, Compression, and Static RSA

TLS 1.3 is often described as TLS 1.2 with the handshake reorganised. The reorganised handshake is visible; the removals are less so, and they account for most of the compatibility work that deploying 1.3 required. Each removal closed an attack or eliminated a construction that could not be made safe at reasonable cost, and each left behind a class of peer that could no longer connect.

Renegotiation is gone, and its replacement is different

TLS 1.2 allowed either side to run a new handshake inside an established connection. The feature existed for a real reason: a server that wants to request a client certificate only after seeing the resource the client asked for cannot do so in the first handshake, because the request must come before the request. Renegotiation let it ask later.

The problem was that the new handshake was not bound to the old one. An attacker who could inject bytes into the connection could initiate a renegotiation that the peer would process as if it came from the legitimate endpoint, and then splice the client’s own request into the new handshake. The result, described as the renegotiation vulnerability, was that a client’s traffic could be authenticated as a server’s. The fix was RFC 5746, which added a renegotiation_info extension carrying a value derived from the previous handshake’s verify data. Both sides had to support it, and a peer that did not could be distinguished but not protected.

TLS 1.3 removed renegotiation entirely. A post-handshake CertificateRequest message replaces the legitimate use case: the server can ask for a client certificate after the handshake completes, and the client answers with Certificate, CertificateVerify, and Finished. Because these messages travel inside the encrypted record layer under keys bound to the original handshake, there is no unbound second handshake to attack. The replacement covers the case that motivated renegotiation without reintroducing the primitive that made it dangerous.

The compatibility cost fell on servers that used renegotiation to change parameters mid-connection, such as moving to a stronger cipher or requesting client authentication based on the URL. A 1.3 connection cannot do either, and the alternatives are a new connection or a post-handshake message that covers only the certificate case.

Compression was removed rather than repaired

TLS 1.2’s record layer offered compression, negotiated through a compression_methods list in the ClientHello. The null method had to be present; other methods were optional. Compressing before encrypting saves bandwidth on text-heavy traffic and was, briefly, appealing.

The construction leaks. An attacker who can inject chosen plaintext into the same compression context as a secret can observe how the ciphertext length changes and infer the secret’s content one byte at a time. The mechanism is the same one that makes CRIME and BREACH work against HTTP compression: compression replaces repeated strings with references, so a guess that matches part of the secret compresses better than one that does not, and the length difference is observable even though the content is not.

Removing compression from the protocol was the only reliable fix, because the leak is a property of compressing attacker-influenced data alongside secrets, not of a particular algorithm. TLS 1.3 keeps the field for compatibility but restricts it to the null method, so a 1.3 client that offers compression gets none. Application-layer compression above TLS is unaffected by the protocol, and the same hazard applies to it; the protocol’s decision is only that the record layer will not be the place where it happens.

Static RSA key exchange and the loss of forward secrecy

TLS 1.2 offered a key exchange in which the client generated a premaster secret, encrypted it with the server’s RSA public key, and sent it. The server decrypted it. The server’s certificate key was therefore the key exchange key, and the same long-lived private key was used for every connection.

Two consequences followed. The first is the absence of forward secrecy: anyone who obtains the server’s private key can decrypt any recorded session that used RSA key exchange, retroactively, because the premaster secret is recoverable from the ciphertext. The second is that the Bleichenbacher attack against PKCS#1 v1.5 padding applies, and although implementations added countermeasures that made the attack harder to mount, the countermeasures were subtle and repeatedly got wrong.

TLS 1.3 requires ephemeral key exchange for every non-PSK connection. The server’s certificate key signs the transcript in CertificateVerify and is never used to transport key material, so compromise of that key does not reveal past sessions. Forward secrecy becomes a property of the protocol rather than a choice made by whoever configured the cipher suite list. The cost is a Diffie-Hellman or elliptic-curve operation per connection, which is cheap on modern hardware and was the reason the trade became acceptable.

The cipher suite list collapsed

In TLS 1.2 a cipher suite name encoded four independent choices: key exchange, authentication, bulk cipher, and hash. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 names an ephemeral elliptic-curve key exchange, an RSA signature, AES-128-GCM, and SHA-256. The list had hundreds of possible combinations, most of them unusable, and a server’s configuration was a statement about which combinations it would accept.

TLS 1.3 separated the two axes. The cipher suite now names only the AEAD and the hash: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. Key exchange is negotiated through the supported_groups and key_share extensions, and authentication through signature_algorithms. A server that wants to offer both RSA and ECDSA certificates does so by having both keys, not by listing suites.

The separation removed a class of misconfiguration, because a suite can no longer encode an invalid pairing of key exchange with certificate type. It also removed the ability to express preferences in the old granularity: a client can no longer say it prefers one key exchange with one cipher over another key exchange with the same cipher, except through the ordering of the extensions. The three defined suites are few enough that the ordering question mostly disappears.

ChangeCipherSpec, session IDs, and the compatibility layer

Several TLS 1.2 mechanisms have no role in 1.3 but remain on the wire. ChangeCipherSpec is a record-layer message announcing that subsequent records use new keys; 1.3 derives keys at defined points in the handshake and has no such announcement, so the record layer treats a received one as a compatibility artefact to be dropped. It is still sent, with a single byte, so that middleboxes which expect it do not drop the connection. compression_methods must contain exactly one entry, the null method. The legacy session ID field is repurposed as a compatibility echo.

These vestiges are the visible price of deploying a new version on an old internet. The protocol’s own downgrade protection is the other half: a server negotiating 1.2 sets a sentinel in its random, and a 1.3-capable client that sees the sentinel aborts rather than proceeding at the lower version. Without that check, an attacker who could strip the supported_versions extension could force a downgrade to a version with weaker guarantees, and the client would have no way to tell.

What the removals cost in practice

A 1.3-only stack cannot talk to a peer that only supports 1.2, so real deployments negotiate both and keep the 1.2 path configured. The 1.2 path retains every weakness described here unless the operator restricts it: disabling static RSA suites, disabling compression, requiring the renegotiation indication, and requiring the extended master secret extension from RFC 7627, which binds the session keys to the handshake transcript and closes a related class of cross-protocol attacks. A server that offers 1.3 and leaves 1.2 wide open has removed nothing for the clients that fall back.

The removals also shifted work upward. Client certificates requested after the fact, parameter changes mid-connection, and compression all became application concerns. That is the consistent pattern in the 1.3 design: a smaller protocol with fewer knobs, and the remaining decisions moved to layers that can make them with more context. The record layer’s own limits, discussed in AEAD usage limits, follow the same philosophy, replacing an implicit assumption with an explicit rule.