EXERCISE 2 — Why TLS 1.3 is 1-RTT but 1.2 was 2-RTT
====================================================

THE 1.2 BOTTLENECK:
  In TLS 1.2 the client could NOT send its key-exchange share until it knew
  the server's choices, because the cipher suite (and thus the key-exchange
  group/parameters) was still being negotiated:
     RT1: ClientHello -> ServerHello + Certificate + ServerKeyExchange
          (only NOW does the client learn the chosen group + server's DH value)
     RT2: ClientKeyExchange + Finished -> server Finished
          (only NOW is the shared secret usable on both sides)
  -> two full round trips before application data.

WHAT 1.3 CHANGES — the client sends its DH share IMMEDIATELY:
  - In 1.3, key exchange is ALWAYS ephemeral (EC)DHE (no RSA transport, no
    static DH to negotiate), so there's far less to agree on.
  - The client therefore puts its OWN (EC)DHE public value — the "key_share"
    extension — right inside the ClientHello, BEFORE hearing back from the
    server. This is the thing it couldn't do in 1.2.
  - The server, on receiving ClientHello, already has the client's share. It
    sends back its own key_share in ServerHello, and now BOTH sides can
    derive the shared secret. The server immediately uses it to encrypt and
    send Certificate + CertificateVerify + Finished in that SAME flight.
  - After one round trip the client has everything: it verifies, sends its
    Finished, and can send application data. => 1-RTT.

THE ASSUMPTION THAT MAKES IT WORK:
  - The client must GUESS which key-exchange group the server will accept,
    because it has to pick one to send a share for. It guesses the most
    common group (typically X25519). Almost always correct.

WHEN THE GUESS IS WRONG — HelloRetryRequest:
  - If the server doesn't support the guessed group, it replies with a
    HelloRetryRequest naming a group it DOES support.
  - The client resends ClientHello with a key_share for that group.
  - This adds one round trip back -> effectively 2-RTT for THAT connection.
  - Because the popular groups are near-universally supported, HRR is rare,
    so the common case stays a clean 1-RTT.

ONE-LINE SUMMARY:
  1.2 waited for the server to choose before the client could contribute
  its key share; 1.3 lets the client contribute up front (by guessing the
  group), collapsing two round trips into one.