EXERCISE 3 — Which requests are safe as 0-RTT early data?
=========================================================

THE GENERAL RULE:
  0-RTT early data can be REPLAYED by an attacker (no fresh server
  randomness protects it yet). So it is safe ONLY for IDEMPOTENT requests —
  ones where processing the request twice has the same effect as once and
  causes no side effect / state change. If replaying it could cause harm or
  duplicate an action, it must NOT be sent as 0-RTT.

Idempotent, read-only, no state change  -> SAFE for 0-RTT.
State-changing / non-idempotent action  -> NOT safe for 0-RTT.

(a) GET /news/today
    SAFE. A GET that just reads an article is idempotent and read-only;
    replaying it only re-fetches the same page. No harm. Classic 0-RTT use.

(b) POST /transfer?amount=500
    NOT SAFE. This moves money — a non-idempotent, state-changing action. A
    replay could execute the transfer a SECOND time, sending $500 twice.
    Exactly the case the Chapter 7 warning calls out. Must go in a normal
    1-RTT request.

(c) GET /account/balance
    MOSTLY SAFE, with a caveat. It's an idempotent read, so a replay just
    re-reads the balance — no state change, so replay-safety is fine.
    Caveat: it returns sensitive data and 0-RTT early data has weaker
    forward-secrecy properties, so some deployments still avoid 0-RTT for
    authenticated/sensitive responses. By the pure replay rule: safe; by a
    conservative policy: you might keep it 1-RTT.

(d) POST /comments  (adds a comment)
    NOT SAFE. Creating a comment is a state-changing, non-idempotent write.
    A replay would post the SAME comment twice (duplicate side effect). Send
    as normal 1-RTT.

QUICK TEST TO APPLY:
  "If this exact request were silently delivered twice, would anything bad
   or duplicated happen?"
     No  -> 0-RTT is acceptable (typically safe GETs).
     Yes -> require 1-RTT (writes, payments, anything non-idempotent).

  In practice servers/frameworks enforce this by only allowing GET (and
  other safe methods) over 0-RTT and rejecting early data for the rest.