RFC 9001 Quiz

**Explanation:** QUIC には TLS に似た独自 handshake がある, と誤解されがちです. ここを正すのが最初の一歩です. **TLS 1.3** は cryptographic handshake と key schedule を担います. **QUIC** は transport と packet 保護の枠組みを担います. bug が TLS library 由来か, QUIC transport 実装由来か, あるいは両者のつなぎ込み由来かを切り分けるときに重要です. - A (incorrect): TLS 1.3 を置き換えるわけではありません. - B (correct): RFC 9001 の中心を正しく捉えています. - C (incorrect): それは QPACK の領域です. RFC 9001 は「QUIC が TLS を使う」と言うだけでなく, どう噛み合わせるかを operational に説明する文書です.

**Explanation:** Initial, Handshake, 1-RTT というラベルだけ覚えても, 実装や debug にはつながりません. **encryption level** は, handshake の進み具合に応じた保護レベルです. それぞれ別の秘密情報と packet 保護文脈に結びつきます. どの frame がどの段階で送れるか, なぜ decrypt 失敗が起きるかを考えるときに必要です. - A (incorrect): HTTP semantics ではありません. - B (incorrect): key schedule を置き換えるものでもありません. - C (correct): これが operational な理解です. encryption level で考えると, QUIC setup を 1 本の直線ではなく段階ごとの保護切り替えとして理解しやすくなります.

**Explanation:** transport parameter は TLS handshake に載るので, TLS の generic option だと思い込むと誤ります. **transport parameter** は QUIC-specific な設定値です. ただし交換の場は TLS handshake の中です. peer mismatch, flow control, 設定値の食い違いを調べるときに, 「TLS が運ぶが QUIC が解釈する」という構図が役立ちます. - A (correct): 場所と意味を正しく言えています. - B (incorrect): HTTP header とは無関係です. - C (incorrect): DNS で運ぶ話ではありません. 境界をまたぐ概念は, 「どこを通るか」と「誰が意味づけするか」を分けて覚えると崩れません.

**Explanation:** 0-RTTのlatency benefitは, application operationが受けるreplay riskと同時に評価する必要があります. **0-RTT** は handshake 完了前に application data を送る仕組みです. **replay** は同じ early data が再受理される危険です. cached GET, idempotent API, login shortcut などで, 早さを優先するか replay 安全性を優先するかの判断に出ます. - A (correct): 速度向上と replay risk はセットです. - B (incorrect): write operation が勝手に安全になるわけではありません. - C (correct): replay-safe な操作に限るのが基本です. - D (incorrect): server 側 policy は依然として必要です. 0-RTT は transport 最適化ですが, 安全に使えるかどうかは application semantics 次第です.

**Explanation:** packet protectionがQUICに組み込まれていても, certificate authenticationとkey scheduleはTLSの責務です. **certificate authentication** と **key schedule** は TLS 1.3 が定める仕組みです. QUIC はその結果を transport に組み込みます. bug が certificate validation policy なのか, packet 処理なのかを切り分けるときに役立ちます. - A (incorrect): これは QUIC transport の話です. - B (incorrect): connection ID policy も QUIC transport の領域です. - C (correct): ここは TLS 由来の責務です. 大事なのは「暗号に関係しているか」ではなく, 「その意味やルールを誰が定義しているか」です.

**Explanation:** 「QUIC は TLS over UDP」という雑な理解を修正するために必要なポイントです. 伝統的な **TLS record layer** は TLS over TCP の wire format です. QUIC では TLS handshake data は **CRYPTO frame** などを通じて packet 処理へ統合されます. parser 実装, observability, Wireshark 的な見方, stack の責務説明で重要です. - A (correct): architecture を正しく表しています. - B (incorrect): そういう禁止はありません. - C (incorrect): QUIC は最後まで plaintext のままではありません. 「TLS を使う」と「TLS record をそのまま流す」は同じ意味ではありません.

**Explanation:** A: application protocol, transport parameter, streamの前提がnew connectionでは異なり得るため, byte再送だけでは不十分です. B: 無効になるstateはpacket numberingより広く, early streamに結び付いたapplication stateも含みます. C: RFC 9001 Section 4.6.2は0-RTT rejection時, application stateを含む全streamのresetを要求します. D: rejectionは定義済みの結果であり, それ自体はprotocol違反ではありません. serverは拒否した0-RTT packetを処理してはなりません. 判定基準: early-dataの各前提は0-RTT acceptanceを条件とし, rejectionならその前提で作ったstreamとapplication stateをrollbackします.

**Explanation:** A: TLS post-handshake authenticationはconnection scopeであり, multiplexingのため発端のapplication eventと確実に対応付けられません. B: RFC 9001 Section 4.4はhandshake中のclient認証要求を許しますが, post-handshake CertificateRequestを禁止します. application認証は別の有効な設計です. C: TLS handshake messageはCRYPTO frameで運びます. CertificateRequest byteをSTREAM frameへ移しても有効な認証protocolにはなりません. D: connection IDはtransport identifierであり, 新しいTLS handshakeや認証境界ではありません. 判定基準: handshake-time TLS client認証か明示的なapplication mechanismを選びます. QUICはoperation起点のpost-handshake CertificateRequestを許しません.

**Explanation:** A: replayは有効なsignatureとgrantを保ったままauthorized state changeを繰り返せます. grant validityはreplay detectionではありません. B: session ticketはresumptionを可能にしますが, RFC 9001はapplicationのexactly-once executionを与えません. C: RFC 9001 Section 9.2はapplication protocolに0-RTT利用とreplay protectionの記述を求めます. ruleがなければ除外する方針が適合します. D: address validationはamplificationを制限しreachabilityを示しますが, capture済みearly requestのreplayを防ぎません. 判定基準: application profileがreplay consequenceを定義し, 対象operationがpolicyを満たす場合だけ0-RTTを受理します. grant, channel, replayは独立に検査します.

**Explanation:** A: old keyでprotectしたacknowledgmentではresponderがnew phaseへ移ったことを確認できません. B: RFC 9001 Section 6.2はupdated keyで受信したpacketをacknowledgeする前にsend keyを更新するよう要求します. C: QUICはTLS KeyUpdate messageを使わず, Section 8.4ではその受信をconnection errorとします. D: 必要な確認後はpeerがupdateを開始できます. next keyで正常に処理できればresponse procedureを開始します. 判定基準: 通常のpacket送信timingは保てますが, trigger packetへの次のacknowledgmentはupdated send keyでprotectします.