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:** **問題を出した背景:** QUIC は速い, だから 0-RTT も無条件に使ってよい, という雑な理解を避けるための設問です. **用語:** **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:** **問題を出した背景:** encrypted packet が出てくると全部 QUIC 側の責務に見えてしまう, という混乱を避けたい設問です. **用語:** **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:** **問題を出した背景:** transport parameter を単なる付随情報だと思うと, setup failure の本丸を見逃します. **用語:** **negotiated state** とは, handshake を通じて両 peer が共有した前提です. transport parameter はその中心にあります. **実務での機会:** interop test, version skew, flow-control 関連の事故で, 「設定した」ではなく「相手にどう伝わったか」を確認する必要があります. **選択肢:** - A (incorrect): HTTP downgrade の話に直結するわけではありません. - B (correct): transport の前提不一致は setup failure の原因になります. - C (incorrect): transport そのものに大きく影響します. **関連:** negotiation 系の bug は, 設定ファイルを見るだけではなく, 実際に合意された値を見るのが近道です.

**Explanation:** **問題を出した背景:** connection ID や packet 保護が見えてくると, identity 保証まで QUIC transport が担うように錯覚しやすいです. **用語:** **certificate validation** と **authenticated handshake transcript** が, server identity の根拠です. transport identifier はその代わりにはなりません. **実務での機会:** 「encrypted packet が来ているから相手は本物だろう」という危うい議論を避けるときに重要です. **選択肢:** - A (incorrect): packet number は認証の根拠ではありません. - B (incorrect): connection ID は continuity や routing に関わりますが, identity の根拠ではありません. - C (correct): ここが server authentication の土台です. **関連:** QUIC の transport feature は便利ですが, trust の根は TLS 側にあると押さえておくと整理しやすいです.

**Explanation:** **問題を出した背景:** RFC 9001 の難しさは, failure が TLS だけでも QUIC だけでもなく, その境界に出ることがある点です. **用語:** **cryptographic handshake** と **QUIC-specific state** は密接ですが同一ではありません. 両方が整って初めて接続が成立します. **実務での機会:** browser, server, proxy の incident で, 「TLS は進んでいるのに接続が成立しない」状況を読む枠組みとして使えます. **選択肢:** - A (correct): 一番実務的で, RFC 9001 的な見方です. - B (incorrect): QUIC 側の不整合は依然として起こり得ます. - C (incorrect): validation を切るのは fix ではなく, security model を壊します. **関連:** setup failure を見るときは, どの layer の前提が破れたかをまず特定するのが近道です.

**Explanation:** **問題を出した背景:** RFC 9001 の学習ゴールは packet 詳細の暗記ではなく, crypto と transport の結合点を architectural に説明できることです. **用語:** **TLS responsibilities**, **QUIC transport responsibilities**, **transport parameter**, **encryption level** は review の中心論点です. **実務での機会:** 実装 review, interop test, incident review で, どこに test を足すべきか, どこに境界条件があるかを見つけやすくなります. **選択肢:** - A (incorrect): QUIC 導入で TLS 的な論点が消えるわけではありません. - B (correct): これが最も成熟した見方です. - C (incorrect): failure は TLS, QUIC, その統合部のどこにもあり得ます. **関連:** RFC 9001 を本当に使える知識にするには, 「QUIC uses TLS」という一文を, 実装責務の分解まで落として話せるようになることが大事です.