Chapter 02 · QUIC Connection Establishment and Security Handshake
Check your understanding
14 questionsself-scored · offline
Answer to check your grasp of Chapter 02. Multiple-choice and true/false questions score themselves and reveal an explanation; short-answer questions reveal a model answer. Nothing leaves your browser.
- Q1multiple choiceIn a QUIC handshake, the TLS 1.3 messages (ClientHello, Certificate, Finished, …) travel inside what?WhyQUIC uses the TLS handshake but not the TLS record layer; TLS messages ride in CRYPTO frames across the Initial and Handshake packet number spaces. [§2.1, RFC 9001 §4]
- Q2multiple choiceWhich encryption level's keys can any on-path observer compute?WhyInitial keys come from a public salt and the client's Destination CID (which is on the wire), so they provide integrity and a common format, not confidentiality. [§2.1, §2.2, RFC 9001 §5.2]
- Q3true / falseA QUIC handshake is 'confirmed' at the moment the local TLS stack finishes.WhyThat is 'complete'. It is 'confirmed' later: at the server when it sends HANDSHAKE_DONE, at the client when it receives one. Confirmation gates key update and the discard of Initial/Handshake keys. [§2.1, RFC 9001 §4.1.2]
- Q4multiple choiceFrom each traffic secret, QUIC derives three values using fixed labels. Which three?WhyHKDF-Expand-Label with the labels 'quic key', 'quic iv', and 'quic hp' produces the AEAD key, the IV, and the header-protection key at every level. [§2.2, RFC 9001 §5.1]
- Q5multiple choiceHow is the AEAD nonce for a packet formed?WhyThe packet number is left-padded to the IV length and XORed with the IV. Because the nonce depends on the packet number, a number must never repeat within a space. [§2.2, RFC 9001 §5.3]
- Q6multiple choiceA trace shows a CONNECTION_CLOSE with error code 0x012a. What does it mean?Why0x0100–0x01ff is CRYPTO_ERROR; the low byte is the TLS AlertDescription. 0x12a − 0x100 = 42 = bad_certificate — the peer rejected the certificate. [§2.5, RFC 9001 §4.8]
- Q7true / falseBecause 0-RTT data is encrypted, it is safe from replay attacks.Why0-RTT keys derive entirely from the old PSK with no fresh server input, so a captured 0-RTT flight can be replayed and reprocessed. Encryption does not prevent replay. [§2.3, RFC 9001 §9.2]
- Q8multiple choiceWhich request is appropriate to send as 0-RTT early data?WhyOnly idempotent operations belong in 0-RTT, because a replay must be harmless. GET is safe; POST/PUT/DELETE that mutate state are not. [§2.3, RFC 9114 §10.9]
- Q9multiple choiceDuring migration, what proves the peer is really reachable at a new address?WhyThe endpoint sends 8 unpredictable bytes in PATH_CHALLENGE; a correct PATH_RESPONSE echo proves reachability and a working return path before the endpoint commits to the path. [§2.4, RFC 9000 §8.2]
- Q10multiple choiceWhen a connection migrates to a new path, an endpoint MUST reset which state?WhyA new path may have a different bottleneck, RTT, and loss rate, so carrying the old path's congestion window and RTT would be wrong. [§2.4, RFC 9000 §9.4]
- Q11true / falseIn QUIC v1, only the client migrates; the server keeps its address (apart from an optional preferred_address).WhyMigration is a client capability in QUIC v1; the server does not change its address mid-connection except via the preferred_address transport parameter. [§2.4, RFC 9000 §9]
- Q12multiple choiceA client sends its Initial packet and gets nothing back at all. The most likely cause is:WhyTotal silence (no CONNECTION_CLOSE) points to the datagram never being processed — under the 1200-byte Initial floor, or UDP filtered on the path — not a TLS rejection, which would send an error. [§2.5, §1.4]
- Q13short answerWhy must 0-RTT be restricted to idempotent operations?Model answer0-RTT early data is protected by keys derived only from a previously issued PSK, with no fresh contribution from the server. An attacker can therefore capture the 0-RTT flight and replay it; the server derives the same keys and processes it again. Only idempotent operations (e.g. GET) are safe under replay, so non-idempotent requests must wait for 1-RTT. [§2.3, RFC 9001 §9.2, RFC 9114 §10.9]
- Q14short answerDistinguish a 'complete' handshake from a 'confirmed' one, and say why the difference matters.Model answerA handshake is complete at an endpoint when its own TLS stack has finished (client after the server's Finished, server after the client's). It is confirmed later: at the server the moment it sends HANDSHAKE_DONE, at the client the moment it receives one. Confirmation matters because key updates are forbidden until confirmed, and the Initial/Handshake keys and packet number spaces are discarded around these points. [§2.1, RFC 9001 §4.1.2]