TLS 1.2 versus TLS 1.3, and why the difference reaches your configuration

There is no longer a standalone TLS 1.2 document. RFC 9846, published in July 2026, obsoletes RFC 8446 and RFC 5246 together, and what remains of TLS 1.2 lives in its Appendix D. That reorganisation matters less than what the RFC records in its own list of major differences, because several of those differences quietly invalidate configuration habits that engineers still carry from a decade of TLS 1.2 practice.

The differences the RFC itself records

Read the third row again. In TLS 1.2, forward secrecy was a property you obtained by choosing ephemeral suites and excluding the static ones. In TLS 1.3 it is structural: there is no mode in which the certificate key transports key material, so there is no static option left to accidentally leave enabled.

Cipher suite names stopped meaning the same thing

A TLS 1.2 suite name is a four-part description. Take TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: ECDHE is the key exchange, RSA is the authentication, AES-128-GCM is the record protection, and SHA256 is the hash. One string, four decisions.

A TLS 1.3 suite name is a two-part description. RFC 9846 Appendix B.4 states that a cipher suite defines the pair of AEAD algorithm and hash algorithm to be used with HKDF, following the convention TLS_AEAD_HASH. There are five defined suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256. None of them names a key exchange or an authentication algorithm, because those moved to the supported_groups and signature_algorithms extensions.

flowchart TD
    A["TLS 1.2 suite name\nTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"] --> B["key exchange ECDHE"]
    A --> C["authentication RSA"]
    A --> D["record protection AES-128-GCM"]
    A --> E["hash SHA256"]
    F["TLS 1.3 suite name\nTLS_AES_128_GCM_SHA256"] --> G["record protection AES-128-GCM"]
    F --> H["hash SHA256"]
    I["supported_groups and key_share"] --> J["key exchange decided here"]
    K["signature_algorithms"] --> L["authentication decided here"]

The diagram shows why the two families cannot be mixed. RFC 9846 is explicit that although TLS 1.3 uses the same cipher suite number space as earlier versions, its suites are defined differently and cannot be used for TLS 1.2, and TLS 1.2 suites cannot be used with TLS 1.3. Writing TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in a document as a “TLS 1.3 cipher suite” is not loose phrasing, it is a category error.

OpenSSL makes the split visible. Ask it to resolve a strictly TLS 1.2 cipher list:

openssl ciphers -s -v 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'

TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128)            Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128)            Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(128)            Mac=AEAD

Two things are worth staring at. The three TLS 1.3 suites appear even though the list named neither of them, because the 1.2 cipher string does not govern them. And their Kx and Au columns both read any, which is the tool telling you that the suite name carries no key exchange and no authentication information at all. The TLS 1.2 rows still carry real values in those columns.

What was removed, and what took its place

Renegotiation is gone. RFC 9846 states plainly that renegotiation is not possible once TLS 1.3 has been negotiated, and RFC 9325 scopes its own renegotiation advice to TLS 1.2 only for that reason. The renegotiation_info extension and the Extended Main Secret extension are TLS 1.2 requirements, not TLS 1.3 hardening steps. Anyone adding them to a TLS 1.3 checklist is protecting against an attack the version does not permit.

What replaced renegotiation are two narrower mechanisms. Post-handshake authentication lets a server request a client certificate after the handshake completes, for the case where only some resources need it. Key and initialisation vector update lets either side roll the traffic keys without a new handshake, and RFC 9846 upgraded the requirement to initiate a key update before exceeding key usage limits from a recommendation to a MUST, while also limiting how many KeyUpdate messages are permitted.

TLS-level compression is gone from TLS 1.3, and RFC 9325 says implementations and deployments should not support it at all. Custom Diffie-Hellman groups are gone, which means the DH parameter file that many older deployment guides told you to generate has no role. Multi-stapling as defined in RFC 6961 is deprecated: RFC 9846 states that TLS 1.3 servers must not act on its presence.

Where TLS 1.2 still lives, and what that now means

TLS 1.2 is not forbidden, but it has stopped moving. RFC 9851, from July 2026, places TLS 1.2 in feature freeze: no changes will be approved outside urgent security fixes, new exporter labels and new ALPN protocol identifiers, and the freeze applies to TLS rather than DTLS. The practical consequence is stated even more directly in RFC 9852, which records that the working group is focusing on TLS 1.3 or later and that TLS 1.2 will not be supported.

The concrete effect is that post-quantum key exchange will never arrive for TLS 1.2. The hybrid mechanisms defined in RFC 10024, including X25519MLKEM768, are TLS 1.3 constructions. If your estate has an endpoint that can only speak TLS 1.2, you have already established the date by which it must be replaced, whether or not anyone has written that date down.

Where TLS 1.2 remains in service, the TLS 1.2 specific requirements still apply. RFC 9325 requires TLS 1.2 clients and servers to implement renegotiation_info, requires clients to send it in the ClientHello and to raise a fatal handshake failure if the server does not acknowledge it, and requires support for the extension now named Extended Main Secret. Those obligations belong to the TLS 1.2 half of your configuration and to nothing else.

Production discipline

1. Configure the two versions as two separate controls. Prove each one by negotiating a connection that pins to that version, not by reviewing the configuration file that was supposed to set it.
2. Delete dead TLS 1.2 furniture from TLS 1.3 deployments. Custom Diffie-Hellman parameter files, compression settings and renegotiation hardening are inert, and leaving them implies a control that does not exist.
3. Record which endpoints are TLS 1.2 only and why. That list is your post-quantum migration backlog, because the feature freeze means those endpoints will never gain hybrid key exchange.
4. Reject documents that write a TLS 1.2 suite name as a TLS 1.3 suite. The mistake usually travels with a compliance claim, and it means nobody tested what was actually negotiated.

Cross-course references

• Linux for Production Sysadmins - Part LXXI (TLS) covers the service-level directives where these two controls are separately expressed, and where a dead parameter file usually survives.
• Kubernetes for Production Sysadmins - Part LXXVI (Certs) covers the cluster PKI, whose components negotiate their own TLS and inherit the same version and suite questions.
• Observability for Production Sysadmins - Part LXIV (TLSMonitoring) covers recording the negotiated version and suite per endpoint, which is the only evidence that a hardening change reached production.

Quiz