RFC 9001 Quiz

**Explanation:** **Context (why chosen):** 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. **Terms:** **TLS 1.3** provides the cryptographic handshake and key schedule. **QUIC** provides transport, packetization, and encryption-level handling around that handshake. **Real-world usage:** This distinction helps when deciding whether a bug belongs in the TLS stack, QUIC transport logic, or the integration between them. **Options:** - 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. **Related:** 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:** **Context (why chosen):** Engineers often memorize “Initial, Handshake, 1-RTT” as labels without connecting them to what each level permits and why that staging exists. **Terms:** **encryption levels** are handshake stages tied to different secrets and packet protection contexts. They control when packets can be generated and understood. **Real-world usage:** This is crucial when debugging why some frames are allowed only at certain stages or why decryption fails during connection setup. **Options:** - 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. **Related:** 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:** **Context (why chosen):** 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. **Terms:** **transport parameters** are QUIC-specific values exchanged in the TLS handshake. They affect transport behavior such as limits and connection properties. **Real-world usage:** This matters when diagnosing peer mismatch, flow-control setup, or configuration assumptions that were never actually negotiated. **Options:** - 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. **Related:** A healthy mental model is: TLS carries them, but QUIC interprets them.

**Explanation:** **Context (why chosen):** 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. **Terms:** **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. **Real-world usage:** This affects login shortcuts, cached API requests, and any idempotent-vs-non-idempotent design review on top of QUIC. **Options:** - 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. **Related:** Faster handshake paths are only useful when the application semantics can tolerate the changed risk profile.

**Explanation:** **Context (why chosen):** The hard part of RFC 9001 is knowing where the division of labor sits. Not everything involving encrypted packets belongs to QUIC transport design. **Terms:** **certificate authentication** and the **key schedule** come from TLS 1.3 semantics. QUIC uses their outputs but does not redefine those cryptographic responsibilities. **Real-world usage:** This helps teams decide whether a bug belongs in certificate validation policy, TLS library usage, or QUIC packet logic. **Options:** - 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. **Related:** 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:** **Context (why chosen):** This is a subtle architectural point. QUIC uses TLS 1.3, but it does not look like “TLS records carried inside QUIC packets.” **Terms:** **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. **Real-world usage:** This matters when instrumenting traffic, building parsers, or explaining why a normal TLS-over-TCP mental model breaks down for QUIC. **Options:** - 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. **Related:** “QUIC uses TLS” is true, but it does not mean “QUIC looks like TLS over UDP.”

**Explanation:** **Context (why chosen):** Engineers often underestimate transport parameters because they look like just another list of values. In practice they are foundational negotiation inputs. **Terms:** **negotiated state** matters because both peers derive transport behavior from the values exchanged in the handshake. **Real-world usage:** This comes up in interop testing, version skew, and bugs where one stack assumes limits or options the other side never agreed to. **Options:** - A (incorrect): HTTP downgrade is not the normal meaning of transport-parameter mismatch. - B (correct): Broken or mismatched transport assumptions can cause connection failure. - C (incorrect): The impact is often transport behavior itself. **Related:** A useful debugging habit is to ask not only “what did I configure” but “what did the peer actually learn through negotiation.”

**Explanation:** **Context (why chosen):** Connection IDs, packet protection, and TLS authentication all show up together in QUIC, so people sometimes assign identity guarantees to the wrong mechanism. **Terms:** **certificate validation** and the authenticated **handshake transcript** are the basis for server authentication. QUIC transport identifiers do not replace that trust model. **Real-world usage:** This helps prevent incorrect security arguments such as “the connection ID proves the server identity” or “encrypted packets imply correct certificate validation happened.” **Options:** - A (incorrect): Packet number space does not authenticate the server. - B (incorrect): Connection ID stability is not the basis of authentication. - C (correct): This is the actual root of server identity assurance. **Related:** QUIC transport features help continuity and routing, but authentication still comes from the TLS side of the design.

**Explanation:** **Context (why chosen):** RFC 9001 is valuable because it teaches that connection setup problems can live in the seam between protocols, not only in one stack or the other. **Terms:** **cryptographic handshake** and **QUIC-specific state** are related but not identical concerns. A healthy setup needs both to line up. **Real-world usage:** This framing is useful in browser, server, and proxy debugging when “TLS worked” is true in one sense but the QUIC connection still failed to establish cleanly. **Options:** - A (correct): This is the most accurate debugging mindset. - B (incorrect): QUIC-specific setup can still fail even if core TLS processing advanced. - C (incorrect): Disabling validation is not a principled fix and undermines the security model. **Related:** Good QUIC debugging asks “which layer owns this failure” and also “which layer depended on the other one being in a certain state.”

**Explanation:** **Context (why chosen):** The goal of this RFC is not packet-field memorization. It is a clean architectural model for a system where crypto and transport are tightly coupled. **Terms:** **TLS responsibilities**, **QUIC transport responsibilities**, **transport parameters**, and **encryption levels** are the recurring review dimensions that matter in RFC 9001 work. **Real-world usage:** This is the kind of review comment that improves implementation design, test coverage, and incident handling across client and server stacks. **Options:** - A (incorrect): QUIC does not erase TLS-specific reasoning. - B (correct): This is the most complete and operationally useful framing. - C (incorrect): Failures can emerge from either side or from their integration. **Related:** Mature RFC 9001 understanding means you can explain not just “QUIC uses TLS,” but exactly which guarantees come from where and how setup can still go wrong.