Summary

  • Key Phaseの反転は、次の鍵とIVでパケットを正常処理して初めて、確認済みの鍵更新になる。
  • その成功は相手が当該接続で更新を始めたことを示すが、理由や旧鍵の消去は証明しない。
  • 原因を論じるには、パケット、鍵世代、確認応答、配備、方針監査の記録を結合する必要がある。

ソフトウェア配備の最中に監視画面がKey Phaseの反転を示し、障害対応者が「セキュリティ上の鍵ローテーション」と記録する。時刻の一致は手掛かりだが、その理由は一ビットの信号には入っていない。

RFC 9001の第6節がKey Phaseに与える役割は限定的だ。1-RTTパケットを保護する鍵世代を示し、初期値0から更新ごとに反転する。QUICはTLS KeyUpdateメッセージではなく独自の仕組みを使う。分かるのは、どの鍵が有効であるべきかであって、運用上の判断ではない。

証拠の境界は第6.2節にある。異なるフェーズを見た受信側は次の鍵とIVを試し、処理に成功した場合だけ、相手が更新を始めたと確定する。受信側はそのパケットへのACKを送る前に送信鍵も更新し、新しい鍵で保護したACKが更新完了を知らせる。したがって、ビットだけが見えて復号結果のないトレースは、見かけの遷移にすぎない。

順序にも制約がある。第6.1節は、ハンドシェイク確認前の更新と、現フェーズのパケットがACKされる前の再更新を禁じる。ヘッダー保護鍵は更新されない。旧パケット保護鍵は、新しい鍵でパケットを正常に保護解除するまで保持し、並べ替えで遅れたパケットのため、その後もしばらく残すことが望ましい。

第6.3節と第6.5節は、現在、次、場合によっては前の受信鍵が同時に存在する理由と、タイミング漏えいを避ける要件を示す。偽のフェーズ値は計算を誘発できる。復号失敗だけでは、正当な更新も攻撃も証明できない。

障害記録には、端点の役割、接続指紋、パケット番号、フェーズ、復号結果、送受信鍵世代、ハンドシェイク確認時刻、起点パケット、新鍵によるACK、保持時間、実装ビルド、配備世代、鍵方針の監査イベントを残すべきだ。プロトコルが示すのは暗号状態の連続性であり、意図と原因は周辺記録から説明する。