Prompt and scope
Your service has many long-lived QUIC connections and needs the forward-secrecy benefits of TLS Extended Key Update. Explain capability negotiation, key transitions, old-client and loss handling, and a safe canary and rollback plan.
The IETF QUIC Working Group draft builds on TLS Extended Key Update so long-lived connections can refresh keys without a full handshake. Both peers must support the TLS flags extension and set ExtendedKeyUpdate during the handshake; after negotiation, the session must use the extended process and must not mix it with standard QUIC Key Update. It remains work in progress, so production must pin an implementation version and interoperability results.
What the interviewer evaluates
The interviewer wants the handshake, Key Phase, and packet-number state machine explained as one system, with a clear boundary from RFC 9001. Cover bidirectional state, loss and reordering, old clients, migration, key retirement, rollout metrics, and rollback limits. A strong answer does not present an Internet-Draft as a stable RFC.
Clarifying questions before answering
- Which QUIC/TLS implementations and versions run on each side, and can both be upgraded?
- How long do connections live, and should updates trigger on time, bytes, or security events?
- Are migration, 0-RTT, proxies, or middleboxes in scope?
- Should an old client stay on standard Key Update or be denied a long-lived connection?
- Does rollback happen before handshake, after negotiation, or after a connection has switched keys?
A 30-second answer framework
“I would treat this as capability negotiation plus a per-connection state machine. Enable it only when both peers advertise TLS flags and ExtendedKeyUpdate; otherwise retain the RFC 9001 path. Once enabled, a session cannot mix the two update processes. Each direction tracks key phase, packet numbers, and a bounded old-packet window. Loss and reordering use the protocol’s decryption and confirmation logic; old keys retire after a safety window. Canary by client version, region, or connection ratio, monitor decryption failures, update latency, retransmission, closes, and CPU, and roll back only new handshakes while negotiated connections finish their existing state.”
Step-by-step deep dive
1. Define the negotiation gate
Extended Key Update is not a unilateral switch. Both peers must support the TLS flags extension and set ExtendedKeyUpdate during the handshake. The server stores the result per connection, not as a global mode. Without mutual capability, use standard QUIC Key Update and never send an unexplained Key Phase.
2. Model send and receive state
For each direction track the current key, next key, Key Phase, maximum old-packet window, and update counter. The sender switches phase after an update; the receiver tries current or next keys and advances only after successful decryption and packet-number checks. Transitions must be idempotent: duplicate triggers cannot skip a phase or erase a key still in use.
3. Handle loss, reordering, and confirmation
An update signal can arrive before an old-key packet or after it. Retain bounded old and next-key candidates and follow packet-number and confirmation rules; never retain keys indefinitely. Classify decrypt failures as phase mismatch, authentication failure, or protocol error. Avoid treating reordering as an attack, but also avoid allowing many key candidates to amplify CPU work.
handshake flags -> negotiated?
no -> RFC 9001 key update
yes -> extended update state
-> packet decrypt -> confirm -> retire old key4. Choose triggers and the safety window
Triggers may use connection age, bytes sent, key-use count, or a security event, balanced against congestion, CPU, and application latency. Prepare new key material before switching, wait for enough confirmation, and then retire the old key. Logs contain phase, count, and result, never key material, TLS secrets, or recoverable credentials.
5. Support old clients and migration
Old clients remain on the standard path; server support does not justify rejecting every unnegotiated connection. Migration does not reset negotiation, but a new network path can increase reordering and loss, so reuse the state machine and observe the window again. A proxy or middlebox must not terminate and recreate an unauthorized key state.
6. Design canaries, metrics, and rollback
Canary by client version, region, or connection ratio. Record negotiation success, decrypt failures, Key Phase disagreement, update latency, retransmission, closes, and CPU. On anomalies, stop advertising the capability on new handshakes while negotiated connections finish their original state; do not force an extended connection back to standard Key Update. Pin versions, run interoperability tests, and use sanitized traces as release gates.
7. Test interoperability and key lifecycle
Test both peers, one-sided support, repeated updates, reordering during an update, loss, migration, long idle periods, and close. Verify old keys cannot decrypt after the window and that memory, crash dumps, and debug interfaces do not expose them. Archive the draft version, implementation commit, vectors, and failures so a later draft change remains reproducible.
High-quality sample answer
I would first identify implementation versions, then model the extension as handshake capability plus a bidirectional connection state machine. Enable it only when both peers support TLS flags and set ExtendedKeyUpdate; otherwise retain the RFC 9001 path. A negotiated session uses one update process, with current and next keys, Key Phase, packet numbers, and a bounded old-packet window per direction. Loss and reordering try bounded candidates and advance only after authenticated confirmation, then retire the old key. Triggers use age, bytes, or security events, and logs contain only phase and outcome. Roll out by client version, region, and connection ratio while watching negotiation, decrypt failures, retransmission, closes, and CPU. Rollback stops the capability on new handshakes; existing negotiated sessions finish their state. Interoperability, long-connection, migration, loss, and key-erasure tests pin the implementation because the draft may still change.
Common mistakes
- Enabling the extension on one side and sending a new Key Phase → the peer cannot interpret it → require mutual handshake negotiation.
- Mixing both update processes in one session → Key Phase semantics conflict → fix one state machine after negotiation.
- Retaining old keys forever after loss → memory and attack surface grow → use a bounded window and confirmation.
- Treating every decrypt failure as an attack → reordering is misreported → separate phase, authentication, and protocol errors.
- Forcing existing connections back during rollback → state is corrupted → stop new negotiation and preserve negotiated sessions.
- Logging TLS secrets → keys can leak → log phase, count, latency, and result only.
Follow-up questions and responses
Why not infer support only from a version number?
A version only suggests possible support. The protocol requires explicit flags in the handshake, and compile options and configuration affect real capability. Use the negotiated result.
What if an old-Key-Phase packet arrives during an update?
Keep a bounded old-key candidate window, perform packet-number and authentication checks, and process it according to state. Reject and count packets outside the window instead of trying indefinitely.
Should an idle connection update keys?
Base the decision on key use and risk. Wait for the next send while idle to avoid useless control traffic, but check key state and expiry before sending again.
How do you prove old keys were erased?
In controlled tests, record lifecycle events and inspect memory, crash dumps, and debug interfaces with irreversible test-key markers. Never print secret material in production logs.
How do you manage a draft expiry or revision?
Pin the draft version and implementation commit, maintain an interoperability matrix, and review changes. Canary a new version behind a distinct capability signal; never assume work-in-progress behavior is stable.