TLS 1.3 Basics

What is TLS 1.3?

TLS 1.3 is the latest version of the Transport Layer Security protocol, securing virtually all HTTPS traffic on the internet. It is specified by RFC 9846 (July 2026), which obsoleted the original RFC 8446. It was a major overhaul from TLS 1.2, removing insecure legacy features and introducing mandatory forward secrecy, a faster 1-RTT handshake, and a dramatically simplified cipher suite list.

The TLS 1.3 Handshake

The handshake establishes a secure connection in a single round trip. The client sends its supported parameters and a key share; the server responds with its choice and key share. After the ServerHello, all remaining handshake messages are encrypted using handshake traffic keys derived via HKDF.

Cipher Suites Explained

TLS 1.3 cipher suites only specify the symmetric encryption algorithm and hash — key exchange and authentication are negotiated separately. This is why there are only 5 suites compared to hundreds in TLS 1.2.

Key Exchange: Classical, PQC, and Hybrid

TLS 1.3 uses ephemeral key exchange for every connection, ensuring forward secrecy. With post-quantum cryptography (PQC), three approaches are available:

Key Schedule (HKDF)

TLS 1.3 derives all session keys through a structured key schedule using HKDF (HMAC-based Key Derivation Function). The shared secret from key exchange feeds into a chain of Extract and Expand operations:

These exact secrets are visible in the Simulate tab after running a handshake.

HelloRetryRequest (HRR)

If the server does not support any of the key exchange groups offered in the client's initial ClientHello, it responds with a HelloRetryRequest instead of a ServerHello. This tells the client to retry with a different key share. The result is a 2-RTT handshake instead of the standard 1-RTT.

In the simulator, try configuring the client with only ML-KEM-1024 and the server with only X25519 to observe a group negotiation mismatch.

Post-Quantum Cryptography in TLS

Quantum computers threaten classical key exchange (ECDH) through Shor's algorithm. The "harvest now, decrypt later" attack means adversaries can record encrypted traffic today and decrypt it once quantum computers are available. PQC integration into TLS addresses this by using lattice-based KEMs (ML-KEM) and signatures (ML-DSA).

The trade-off: PQC algorithms have larger keys and ciphertexts, increasing handshake overhead. For example, ML-KEM-768 public keys are ~1,184 bytes vs 32 bytes for X25519. The hybrid approach (e.g., X25519MLKEM768) provides quantum resistance while maintaining classical security as a fallback.

Scaling PQC for HTTPS

PQC signatures are significantly larger than classical ones — an ML-DSA certificate chain can add several kilobytes to every TLS handshake. For the web, where billions of connections happen daily, this overhead is a serious scalability concern. The ecosystem is deploying multiple mitigations.

Merkle Tree Certificates (MTC)

Google's MTC program (announced February 2026) goes further than compression — it replaces entire certificate chains with compact Merkle proofs.

Encrypted Client Hello (ECH)

PQC protects the content of TLS connections from quantum attack, but the initial ClientHello — including the Server Name Indication (SNI) — is sent in plaintext, revealing which site a user is connecting to. Encrypted Client Hello (ECH) solves this by encrypting the ClientHello using a key published in DNS.