<b>Why does a TLS 1.3 cipher suite name no longer tell you the key exchange or signature algorithm?</b>

<b>Why does a TLS 1.3 cipher suite name no longer tell you the key exchange or signature algorithm?</b>

In TLS 1.2, a cipher suite was a verbose bundle: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 named the key exchange (ECDHE), the authentication (RSA), the bulk cipher (AES-128-GCM), and the hash (SHA-256). TLS 1.3 cut this down to five suites, e.g. TLS_AES_128_GCM_SHA256 — and the omission is structural, not cosmetic.

TLS 1.3 decouples the parameters that 1.2 fused. Key exchange is always ephemeral (forward secrecy is mandatory) and is negotiated separately via the supported_groups and key_share extensions. Authentication is negotiated via signature_algorithms. So the suite only needs to name the AEAD (Authenticated Encryption with Associated Data) cipher and the HKDF hash — the two things not covered by other extensions.

This is why the dangerous 1.2 suites are simply absent from 1.3: there is no RSA key transport (it lacks forward secrecy and enabled the Bleichenbacher/ROBOT attacks), no static DH, no CBC-mode ciphers (the source of Lucky13, BEAST, POODLE-class padding-oracle attacks), and no RC4. The negotiation surface that produced a decade of downgrade and oracle attacks was removed by design, not patched.

Evidence vs. speculation: RFC 8446 §1.2 explicitly enumerates the removed features. The reduction is the security argument — fewer negotiable parameters means fewer downgrade combinations.

<b>Further reading:</b> RFC 8446 §1.2, §B.4; RFC 8446 Appendix on removed features.

<b>Bottom line:</b> The short TLS 1.3 suite name reflects that the unsafe options were deleted, not merely deprecated — the suite encodes only the AEAD and hash because everything else is mandatory-secure and negotiated elsewhere.