When a service negotiates TLS 1.3 instead of TLS 1.2, which protocol capabilities are gone, and what relied on them?
answer
- some capabilities are simply gone
- every full exchange is ephemeral now
- no renegotiation, no record compression
- suite names do not carry across versions
- tail encrypted from EncryptedExtensions onward
basics
~20 sTLS 1.3 drops static key transport, so every full handshake uses an ephemeral exchange; it removes renegotiation and record-layer compression; its cipher suites are a separate set from TLS 1.2's; and everything from EncryptedExtensions onward, including the server's certificate, is encrypted.
solid answer
~40 sThe version-level changes that surface in an existing deployment are these. Static key transport is gone: a full TLS 1.3 handshake always performs an ephemeral exchange, so a TLS 1.2 configuration offering only key-transport suites has nothing to offer. Renegotiation is gone, so any design that renegotiated mid-connection - to request a client certificate late, or to rekey a long-lived link - has no equivalent under that name; TLS 1.3 provides separate mechanisms instead. Record-layer compression is gone. The TLS 1.3 cipher suites are a disjoint set naming only an AEAD and a hash, so a hardened TLS 1.2 allowlist constrains nothing once 1.3 is negotiated. And the handshake tail from `EncryptedExtensions` onward - including `Certificate` and `CertificateVerify` - is protected, so only the two hellos remain readable in the path.
go deeper
Recall that TLS 1.3 is not TLS 1.2 with a higher number: some capabilities were removed outright, so a peer moving up can lose behaviour something else depended on.
Name the removals and state each mechanically: ephemeral exchange only, no renegotiation, no record compression, a disjoint suite set, and a handshake tail that is encrypted.
Predict the failures a move causes in an estate: the untouched TLS 1.2 allowlist that now constrains nothing, the undocumented renegotiation, and the path element that read the certificate out of the flight.
Treat a version delta as a migration event with owners and evidence, not a number: decide what must be inventoried before peers start selecting the newer version on their own.
## Why the delta matters more than the version number A deployment rarely moves to TLS 1.3 by decision; it moves when both ends happen to support it and the negotiation picks it. Anything built on a TLS 1.2 assumption then stops working without anyone having changed a configuration file. For a long-lived estate - a metering concentrator talking to devices installed across fifteen years - the questions are which assumptions those are and which side notices first. ## The version-level changes that surface in practice 1. **Every full handshake is ephemeral.** TLS 1.3 removed static key transport, in which a client encrypted a secret to the long-term key behind the server's certificate. A full handshake now always performs an ephemeral exchange, or resumes with a pre-shared key. A TLS 1.2 configuration whose enabled suites were all key-transport suites has nothing that survives the move. 2. **Renegotiation is gone.** TLS 1.2 could restart a handshake inside an established connection. TLS 1.3 has no such capability under that name. Designs that renegotiated to ask for a client certificate once the request path was known, or to refresh keys on a connection that stays up for weeks, have to use the distinct mechanisms TLS 1.3 provides for authenticating after the handshake and for rekeying - neither of which restarts a handshake. 3. **Record-layer compression is gone.** TLS 1.2 could negotiate compression of record payloads. TLS 1.3 offers none, and the field that used to carry the choice survives only as a vestige a client fills with the null value. 4. **The cipher suites are a different set.** A TLS 1.3 suite names an AEAD algorithm and a hash, and nothing else - the key exchange and the signature algorithm are negotiated by their own extensions. The registry entries are disjoint from TLS 1.2's, so the two lists are configured independently. 5. **The handshake tail is encrypted.** From `EncryptedExtensions` onward - so including `Certificate`, `CertificateVerify` and `Finished` - the handshake is protected. In TLS 1.2 the server's certificate travelled in the clear. ## What did not change It is as easy to overstate the delta as to understate it. - The record layer still frames and protects records, and an application still sees a byte stream. - Certificate formats, and the decisions a client makes about a certificate, are not a TLS version matter. - The port, the application protocol above, and the identity the certificate asserts are all untouched. ## The TLS 1.2 versus TLS 1.3 view | Capability | TLS 1.2 | TLS 1.3 | |---|---|---| | Key transport to a long-term key | available | removed; the full handshake is ephemeral | | Renegotiation | available | removed; separate post-handshake mechanisms instead | | Record compression | negotiable | removed | | Cipher-suite strings | name exchange, signature, cipher, hash | name an AEAD and a hash; disjoint registry | | Server `Certificate` message | in the clear | encrypted, with the rest of the tail | ## Where this bites a long-lived fleet - **A configuration that was never rewritten.** An estate that pinned an approved TLS 1.2 suite list and never added a TLS 1.3 list is running its newest connections under whatever default the implementation carries, having believed itself constrained. - **An integration that used renegotiation.** These are usually old, undocumented and discovered only when a peer starts selecting TLS 1.3 - often after a routine update on the other end. - **Anything in the path keyed on the handshake tail.** An element that identified a peer by reading the certificate out of the server's flight sees nothing once TLS 1.3 is in force. The two hellos remain readable; the rest does not. - **A device population that only ever offered TLS 1.2.** Nothing breaks for it - but it also gains none of the above, which is why a version delta and a version floor are separate conversations. ## The direction of each claim Each of these is a change to what the *protocol* offers, not a claim about safety. Negotiating TLS 1.3 does not by itself change which peers a deployment trusts, which names it checks, or which certificates it accepts; those are decided elsewhere and unchanged by the version in force. What the version decides is which mechanisms are on the table at all.
- A deployment pinned a hardened TLS 1.2 cipher-suite allowlist years ago. What does that list do once peers negotiate TLS 1.3?Nothing. The TLS 1.3 suites are a separate set naming an AEAD and a hash, so a TLS 1.2 allowlist selects none of them and constrains none of those connections. The two lists are configured independently, and a deployment that pinned only the older one has not restricted its newest traffic at all.
- A design renegotiated mid-connection to request a client certificate once it saw the request path. What is the TLS 1.3 position?Renegotiation does not exist in TLS 1.3. Authenticating a client after the handshake is a distinct mechanism that both ends must have agreed to in the initial handshake, and rekeying is its own message; neither restarts a handshake, so a design that assumed "renegotiate on demand" has to be rebuilt rather than ported.
saying these in an interview costs you the question
- Thinks TLS 1.2 cipher-suite names carry over to TLS 1.3
- Expects renegotiation to keep working once TLS 1.3 is negotiated
- Believes the server's certificate is still in the clear in TLS 1.3
- Assumes negotiating TLS 1.3 changes which certificates are trusted
- Says record compression is merely off by default rather than removed
- Thinks a full TLS 1.3 handshake can still use key transport