RFC 9001 Quiz

**Explanation:** A common misunderstanding is that QUIC invents a separate TLS-like handshake. RFC 9001 instead explains how TLS 1.3 is used in a QUIC-specific way. **TLS 1.3** provides the cryptographic handshake and key schedule. **QUIC** provides transport, packetization, and encryption-level handling around that handshake. This distinction helps when deciding whether a bug belongs in the TLS stack, QUIC transport logic, or the integration between them. - A (incorrect): QUIC does not replace TLS 1.3 with a new crypto protocol here. - B (correct): This is the core purpose of RFC 9001. - C (incorrect): Header compression for HTTP/3 is QPACK, not RFC 9001. RFC 9001 is best read as the “how QUIC and TLS fit together” document, while RFC 9000 handles transport behavior and RFC 8446 handles TLS semantics.

**Explanation:** Engineers often memorize “Initial, Handshake, 1-RTT” as labels without connecting them to what each level permits and why that staging exists. **encryption levels** are handshake stages tied to different secrets and packet protection contexts. They control when packets can be generated and understood. This is crucial when debugging why some frames are allowed only at certain stages or why decryption fails during connection setup. - A (incorrect): Encryption levels are not HTTP semantics. - B (incorrect): They do not remove the TLS key schedule; they use its outputs. - C (correct): This is the correct operational meaning. Thinking in encryption levels is a good way to understand why QUIC can protect different handshake stages without treating the whole connection as one monolithic state.

**Explanation:** Transport parameters are a classic place where engineers blur protocol boundaries: they are carried via the handshake, but they are about QUIC transport, not generic TLS policy. **transport parameters** are QUIC-specific values exchanged in the TLS handshake. They affect transport behavior such as limits and connection properties. This matters when diagnosing peer mismatch, flow-control setup, or configuration assumptions that were never actually negotiated. - A (correct): This captures both where they are exchanged and what they control. - B (incorrect): They are not HTTP headers. - C (incorrect): DNS does not carry them. A healthy mental model is: TLS carries them, but QUIC interprets them.

**Explanation:** Teams often hear “QUIC is faster” and forget that early data changes the security model. RFC 9001 inherits the TLS 1.3 replay concern rather than erasing it. **0-RTT** allows early application data before handshake completion. **replay** means an attacker may cause early data to be accepted more than once under some conditions. This affects login shortcuts, cached API requests, and any idempotent-vs-non-idempotent design review on top of QUIC. - A (correct): Lower latency is the gain, replay risk is the trade-off. - B (incorrect): Write operations can be dangerous under replay. - C (correct): Replay-safe behavior remains the design principle. - D (incorrect): Anti-replay and policy decisions are still needed. Faster handshake paths are only useful when the application semantics can tolerate the changed risk profile.

**Explanation:** The hard part of RFC 9001 is knowing where the division of labor sits. Not everything involving encrypted packets belongs to QUIC transport design. **certificate authentication** and the **key schedule** come from TLS 1.3 semantics. QUIC uses their outputs but does not redefine those cryptographic responsibilities. This helps teams decide whether a bug belongs in certificate validation policy, TLS library usage, or QUIC packet logic. - A (incorrect): That is QUIC transport and packet-format territory. - B (incorrect): Connection ID policy is a QUIC transport concern. - C (correct): These are fundamentally TLS responsibilities. The useful split is not “encrypted means QUIC” versus “crypto means TLS,” but rather “who defines the semantics that peers are expected to follow.”

**Explanation:** This is a subtle architectural point. QUIC uses TLS 1.3, but it does not look like “TLS records carried inside QUIC packets.” **TLS record layer** is the wire format used in traditional TLS over TCP. QUIC instead carries TLS handshake data in CRYPTO frames and uses QUIC packet protection semantics. This matters when instrumenting traffic, building parsers, or explaining why a normal TLS-over-TCP mental model breaks down for QUIC. - A (correct): This is the architectural reason. - B (incorrect): There is no such prohibition; this answer is nonsense. - C (incorrect): QUIC does not keep everything plaintext until the end. “QUIC uses TLS” is true, but it does not mean “QUIC looks like TLS over UDP.”

**Explanation:** A: Retransmitting bytes is insufficient because the application protocol, transport parameters, and stream assumptions used for 0-RTT might all differ on the new connection. B: The invalidated state is broader than packet numbering and includes application state attached to the early streams. C: RFC 9001 Section 4.6.2 requires the client to reset all streams, including application state bound to them, when 0-RTT is rejected. D: Rejection is a defined outcome, not itself a protocol violation. The server must not process rejected 0-RTT packets. Decision rule: Treat 0-RTT acceptance as the condition for every early-data assumption; rejection rolls back the stream and application state created under those assumptions.

**Explanation:** A: TLS post-handshake authentication is connection-scoped, and multiplexing prevents reliable correlation with the application event that triggered it. B: RFC 9001 Section 4.4 permits the server to request client authentication during the handshake but forbids post-handshake CertificateRequest. Application authentication is a separate valid design choice. C: TLS handshake messages belong in CRYPTO frames; moving CertificateRequest bytes to a STREAM frame does not create a valid authentication protocol. D: A connection ID is a transport identifier, not a new TLS handshake or authentication boundary. Decision rule: Choose either handshake-time TLS client authentication or an explicitly defined application mechanism; QUIC does not permit an operation-triggered post-handshake CertificateRequest.

**Explanation:** A: A replay can preserve a valid signature and grant while repeating the authorized state change. Authorization validity is not replay detection. B: Session tickets enable resumption; RFC 9001 does not give the application exactly-once execution. C: RFC 9001 Section 9.2 places responsibility on the application protocol to describe 0-RTT use and replay protection. With no such rule, excluding this operation is the supported policy. D: Address validation limits amplification and proves address reachability; it does not prevent a captured early request from being replayed. Decision rule: Accept 0-RTT only when the application profile defines replay consequences and the particular operation satisfies that policy. Grant, channel, and replay checks remain independent.

**Explanation:** A: An acknowledgment protected with old keys would not confirm that the responder moved to the new phase. B: RFC 9001 Section 6.2 requires send keys to be updated before acknowledging the packet received with updated keys. C: QUIC does not use the TLS KeyUpdate message; receiving that message is a connection error under Section 8.4. D: A peer can initiate an update after the required confirmation. Successful processing with the next keys triggers the response procedure. Decision rule: Normal packet timing may be retained, but the next acknowledgment for the triggering packet must be protected with updated send keys.