要約

  • 現行文書は draft-ietf-tls-extended-key-update-13 であり、依頼時の第11版は旧版になった。まだ Internet-Draft で、承認済み RFC や導入実績ではない。
  • request、response、finish は新しい共有秘密を導入できるが、旧秘密の削除や両方向の切替を遠隔から証明するものではない。
  • 復旧の判断には、能力交渉、順序、新規材料の生成、導出、旧状態の破棄、方向別の最初の新鍵レコード、アプリケーションの往復確認を結び付ける必要がある。

先に文書の現在地を固定する

IETF Datatracker は第11版を過去の版として扱う。第13版は 2026 年 7 月 4 日に公開され、2027 年 1 月 5 日に期限を迎える。目標は Proposed Standard だが、IESG 上の状態は「I-D Exists」にとどまり、担当 Area Director も telechat 日程もない。

第13版ではサブタイプ2が key_update_finish に改称され、三つの EKU メッセージを旧アプリケーション鍵で保護する点と、能動攻撃者の境界が明確になった。したがって「対応済み」という表現には、実装した版と観測した動作が必要である。「IETF 承認済み」ではない。

コード、方針、セッションは別の事実

クライアントは ClientHello の TLS flags で Extended_Key_Update を提案する。サーバーは対応し、有効化している場合だけ EncryptedExtensions で確認する。確認がなければ、そのセッションに EKU はなく、侵害後安全性を必須とするアプリケーションは完全なハンドシェイクをやり直す。

EKU の合意後は従来の KeyUpdate が禁止され、受信すれば unexpected_message で接続を終える。request と response は初回ハンドシェイクで選んだ鍵交換グループを使わなければならず、別グループは illegal_parameter となる。バイナリの機能、運用方針の有効化、当該セッションの交渉は三つの別々の証拠だ。

接続全体が一瞬で切り替わるわけではない

開始側は新しい key share を持つ key_update_request を送る。応答側は key_update_response を返した後、まず送信鍵を切り替える。開始側は新状態を導出し、受信鍵を切り替え、旧鍵で空の key_update_finish を送り、その後で送信鍵を切り替える。応答側が受信鍵を変えるのは、その旧鍵 finish を認証してからだ。

この間、同じ端点でも送信と受信が異なる世代になり得る。「接続鍵バージョン」という単一値では本質的な非対称性を失う。同時 request では key_exchange の辞書順で小さい側が敗れ、同値なら接続を閉じる。

導出は、新しい共有秘密、以前の main secret に結び付いた値、最初のハンドシェイクと過去の EKU を含む transcript hash を混ぜる。そこから両方向の traffic secret、exporter secret、resumption main secret を作る。通常の KeyUpdate と違い、後継状態は侵害済みの連鎖だけからは決まらない。

プロトコルが証明できない領域

パケット列は新しい share と適合するレコードを示せる。しかし乱数生成器の健全性、エフェメラル材料の非再利用、heap、HSM、カーネルオフロード、クラッシュダンプに旧コピーが残っていないことは示せない。草案は旧秘密を速やかに削除すべきだとするが、相手側はその実行を保証できない。

有用な実行証跡は、秘密を記録せずに、交渉した版とグループ、エフェメラル生成の非秘密ID、三メッセージの識別子、後継世代、各保存層の破棄結果、各方向で新鍵により初めて受理したレコードを一つのセッションへ結ぶ。

さらに、攻撃者が両端から離れていなければならない。常駐する攻撃者は新状態を読む。現在の traffic key を持つ能動攻撃者は、第11節の追加認証を実際に使わない限り、EKU メッセージを置換して中間者の位置を維持できる。一つの接続が復旧しても、侵害された長期 ID 鍵は直らない。

DTLS では epoch、再送、旧状態の一時保持、ACK が加わる。開始側の送信切替は新 epoch の ACK まで完了しない。TLS 用の観測項目を名前だけ変えても DTLS の証拠にはならない。

出典