プロンプトとスコープ
あなたのサービスには多数の長時間稼働する QUIC 接続があり、TLS Extended Key Update による前方秘匿性（forward secrecy）の利点が必要です。機能ネゴシエーション、鍵の遷移、古いクライアントおよび損失の処理、安全なカナリアおよびロールバック計画について説明してください。
IETF QUIC ワーキンググループのドラフトは、TLS Extended Key Update をベースにしており、長時間接続がフルハンドシェイクなしで鍵を更新できるようにします。両方のピアが TLS flags 拡張をサポートし、ハンドシェイク中に Extended_Key_Update を設定する必要があります。ネゴシエーション後、セッションは拡張プロセスを使用する必要があり、標準の QUIC Key Update と混在させてはなりません。ドラフトは作業中（work in progress）であるため、本番環境では実装バージョンと相互運用性の結果を固定（ピン留め）する必要があります。
面接官が評価するポイント
面接官は、ハンドシェイク、Key Phase、パケット番号の状態マシンが、RFC 9001 との明確な境界を持ちつつ 1 つのシステムとして説明されることを求めています。双方向の状態、損失と順序変更、古いクライアント、マイグレーション、鍵の廃棄、ロールアウトのメトリクス、ロールバックの制限を網羅してください。優れた回答では、Internet-Draft を安定した RFC として提示することはありません。
回答前の明確化のための質問
- 各サイドでどの QUIC/TLS 実装およびバージョンが動作しており、双方がアップグレード可能か？
- 接続の持続時間はどの程度で、更新のトリガーは時間、バイト数、またはセキュリティイベントのいずれか？
- マイグレーション、0-RTT、プロキシ、またはミドルボックスはスコープに含まれるか？
- 古いクライアントは標準の Key Update を継続すべきか、それとも長時間接続を拒否すべきか？
- ロールバックはハンドシェイク前、ネゴシエーション後、または接続がすでに鍵を切り替えた後のどのタイミングで発生するか？
30秒の回答フレームワーク
「これを機能ネゴシエーションと接続ごとの状態マシンとして扱います。両ピアが TLS flags と Extended_Key_Update をアドバタイズした場合にのみ有効にし、そうでない場合は RFC 9001 のパスを維持します。一度有効化されたセッションでは、2 つの更新プロセスを混在させることはできません。各方向で鍵フェーズ、パケット番号、制限付きの古いパケットウィンドウを追跡します。損失と順序変更にはプロトコルの復号および確認ロジックを使用し、古い鍵は安全ウィンドウの経過後に廃棄します。クライアントバージョン、リージョン、または接続比率ごとにカナリアリリースを行い、復号失敗、更新レイテンシ、再送、切断、CPU を監視し、ネゴシエーション済みの接続が既存の状態を完了する間、ロールバックは新しいハンドシェイクのみに適用します。」
ステップバイステップの詳細解説
1. ネゴシエーションゲートの定義
Extended Key Update は一方的な切り替えではありません。両ピアが TLS flags 拡張をサポートし、ハンドシェイク中に Extended_Key_Update を設定する必要があります。サーバーは結果をグローバルモードとしてではなく、接続ごとに保持します。相互の機能が確認できない場合は標準の QUIC Key Update を使用し、意図しない Key Phase を送信してはなりません。
2. 送信および受信状態のモデル化
各方向について、現在の鍵、次の鍵、Key Phase、古いパケットの最大ウィンドウ、更新カウンターを追跡します。送信側は更新後にフェーズを切り替えます。受信側は現在または次の鍵を試行し、復号とパケット番号のチェックが成功した後にのみ進めます。遷移は冪等である必要があります。重複したトリガーによってフェーズをスキップしたり、まだ使用中の鍵を消去したりすることはできません。
3. 損失、順序変更、確認の処理
更新シグナルは、古い鍵のパケットより先に到着することも、後に到着することもあります。制限付きの古い鍵および次の鍵の候補を保持し、パケット番号と確認のルールに従います。鍵を無制限に保持してはなりません。復号失敗は、フェーズの不一致、認証失敗、またはプロトコルエラーとして分類します。順序変更を攻撃として扱うことは避けるべきですが、多数の鍵候補によって CPU 負荷が増大することも防ぐ必要があります。
handshake flags -> negotiated?
no -> RFC 9001 key update
yes -> extended update state
-> packet decrypt -> confirm -> retire old key4. トリガーと安全ウィンドウの選択
トリガーには、輻輳、CPU、アプリケーションレイテンシとのバランスを取りながら、接続時間、送信バイト数、鍵の使用回数、またはセキュリティイベントを使用できます。切り替え前に新しい鍵マテリアルを準備し、十分な確認を待ってから古い鍵を廃棄します。ログにはフェーズ、カウント、結果のみを含め、鍵マテリアル、TLS シークレット、復元可能な認証情報は絶対に含めません。
5. 古いクライアントとマイグレーションのサポート
古いクライアントは標準パスにとどまります。サーバー側がサポートしているからといって、ネゴシエーションされていないすべての接続を拒絶する正当な理由にはなりません。マイグレーションによってネゴシエーションがリセットされることはありませんが、新しいネットワークパスによって順序変更や損失が増加する可能性があるため、状態マシンを再利用し、再度ウィンドウを監視します。プロキシやミドルボックスが無許可の鍵状態を終端・再作成してはなりません。
6. カナリア、メトリクス、ロールバックの設計
クライアントバージョン、リージョン、または接続比率によってカナリアリリースを実施します。ネゴシエーションの成功、復号失敗、Key Phase の不一致、更新レイテンシ、再送、切断、CPU を記録します。異常が発生した場合は、ネゴシエーション済みの接続が元の状態を完了する間、新しいハンドシェイクでの機能のアドバタイズを停止します。拡張接続を強制的に標準 Key Update に戻してはなりません。バージョンを固定し、相互運用性テストを実行し、サニタイズされたトレースをリリースゲートとして使用します。
7. 相互運用性と鍵ライフサイクルのテスト
両ピアのサポート、片側のみのサポート、繰り返しの更新、更新中の順序変更、損失、マイグレーション、長時間のアイドル状態、切断をテストします。ウィンドウ経過後に古い鍵で復号できないこと、およびメモリ、クラッシュダンプ、デバッグインターフェースにそれらが露出しないことを検証します。ドラフトの変更が後から発生しても再現性を保てるよう、ドラフトのバージョン、実装コミット、テストベクター、失敗事例をアーカイブします。
高品質な回答サンプル
まず実装バージョンを特定し、その拡張機能をハンドシェイク機能と双方向接続状態マシンとしてモデル化します。両ピアが TLS flags をサポートし、Extended_Key_Update を設定した場合にのみ有効化し、それ以外の場合は RFC 9001 のパスを維持します。ネゴシエーションされたセッションは単一の更新プロセスを使用し、方向ごとに現在の鍵と次の鍵、Key Phase、パケット番号、制限付きの古いパケットウィンドウを持ちます。損失や順序変更に対しては制限付きの候補を試行し、認証済みの確認が得られた後にのみ進め、その後古い鍵を廃棄します。トリガーには接続時間、バイト数、セキュリティイベントを使用し、ログにはフェーズと結果のみを記録します。ネゴシエーション、復号失敗、再送、切断、CPU を監視しながら、クライアントバージョン、リージョン、接続比率でロールアウトします。ロールバック時は新しいハンドシェイクでの機能を停止し、既存のネゴシエーション済みセッションはその状態を最後まで完了させます。ドラフトは今後も変更される可能性があるため、相互運用性、長時間接続、マイグレーション、損失、鍵消去のテストによって実装をピン留めします。
よくある間違い
- 片側でのみ拡張機能を有効にして新しい Key Phase を送信する → ピアがそれを解釈できない → ハンドシェイクでの相互ネゴシエーションを必須とする。
- 1 つのセッションで両方の更新プロセスを混在させる → Key Phase のセマンティクスが競合する → ネゴシエーション後に 1 つの状態マシンに固定する。
- パケット損失後に古い鍵を永久に保持する → メモリと攻撃対象領域が増大する → 制限付きウィンドウと確認ロジックを使用する。
- すべての復号失敗を攻撃として扱う → 順序変更が誤って報告される → フェーズ、認証、プロトコルのエラーを分離する。
- ロールバック中に既存の接続を強制的に以前の方式に戻す → 状態が破損する → 新規ネゴシエーションを停止し、ネゴシエーション済みセッションを維持する。
- TLS シークレットをログ出力する → 鍵が漏洩する可能性がある → フェーズ、カウント、レイテンシ、結果のみをログ出力する。
フォローアップの質問と回答
バージョン番号のみからサポートを推測してはいけない理由は？
バージョンはサポートの可能性を示唆しているに過ぎません。プロトコルはハンドシェイクでの明示的なフラグを要求しており、コンパイルオプションや設定が実際の機能に影響します。ネゴシエーションされた結果を使用してください。
更新中に古い Key Phase のパケットが到着した場合はどうなるか？
制限付きの古い鍵候補ウィンドウを維持し、パケット番号と認証チェックを実行して、状態に応じて処理します。無制限に試行するのではなく、ウィンドウ外のパケットは拒否してカウントします。
アイドル状態の接続でも鍵を更新すべきか？
鍵の使用状況とリスクに基づいて決定します。無駄な制御トラフィックを避けるため、アイドル中は次の送信まで待機しますが、再送信する前に鍵の状態と有効期限を確認します。
古い鍵が消去されたことをどのように証明するか？
制御されたテストにおいて、ライフサイクルイベントを記録し、復元不可能なテスト用鍵マーカーを使用してメモリ、クラッシュダンプ、デバッグインターフェースを検査します。本番ログにシークレットマテリアルを出力してはなりません。
ドラフトの失効や改訂はどのように管理するか？
ドラフトのバージョンと実装コミットをピン留めし、相互運用性マトリクスを維持し、変更点を確認します。個別の機能シグナルの背後で新しいバージョンをカナリアリリースします。作業中のドラフトの動作が安定していると想定してはなりません。