<b>What actually happens when a TLS 1.3 client guesses the wrong key-share group?</b>

<b>What actually happens when a TLS 1.3 client guesses the wrong key-share group?</b>

This is the HelloRetryRequest path, and understanding it explains a measurable latency cost in real handshakes.

TLS 1.3 (RFC 8446) folds key exchange into the first flight. The client doesn't just list supported groups in supported_groups; it speculatively sends actual Diffie-Hellman key shares in the key_share extension for the groups it expects the server to pick — usually X25519 and secp256r1.

If the server's preferred group isn't among the shares the client offered, it cannot complete the exchange from flight one. It returns a HelloRetryRequest (HRR), naming the group it wants. The client then resends a ClientHello with a key share for that group. This adds a full round trip — the very round trip TLS 1.3 was designed to eliminate.

The design tension is explicit: sending shares for every supported group wastes bandwidth and computation, while sending too few risks an HRR. Clients optimize by guessing the most probable group. This is why X25519 (Curve25519, RFC 7748) dominates — it is the near-universal default, so guessing it almost always avoids the retry.

The same machinery now governs post-quantum migration: a client offering X25519MLKEM768 that hits a server wanting classical X25519 eats an HRR.

Further reading: RFC 8446 §4.1.4, RFC 7748, RFC 8422.

Bottom line: HelloRetryRequest is the cost of a wrong key-share guess — one extra round trip, which is why client group-prediction quality directly shapes handshake latency.