Summary

  • IETF 126のCURRENT BoFはMLSでTLS 1.3 record layerの鍵を管理する案を議論したが、CURRENTは未charterで、議事録は問題設定がまだ十分理解されていないと記録した。
  • 二者間profileでは、commitを適用した側が認証済みEpochKeyUpdateを送り新しい材料を使い始める一方、開始側はその確認を検証するまで保留状態をcurrentにできない。
  • 更新送信、ローカル導入、旧秘密削除、新epoch上のアプリケーション成功は、同じ事実ではない。

同じ瞬間に二つの正しい状態がある

AがConnectionUpdateを送る。Bはcommitを検証・適用し、EpochKeyUpdateを返して新しい材料を使い始める。Bの「切替済み」という記録は正しい。しかしAはまだAwaiting EpochKeyUpdateにいる。保留commitから得た状態で確認を認証するまで、Aは新状態をcurrentにしてはならない。

この非対称性は障害ではない。送信者自身の操作を、相手の受信・検証・導入の証明にしないための仕切りである。運用画面が全工程を「ローテーション成功」の一語に畳むときにだけ、正しいローカル記録が誤った全体結論へ変わる。

関連する二文書はいずれも個人Internet-Draftの01版であり、RFC streamを持たない。CURRENTもDatatracker上はBoFで、まだcharterされていない。IETF 126では、問題の範囲、二者プロトコルと多者ユースケースの不一致、既存TLS拡張で解ける範囲が問われた。承認済み標準として扱う根拠はない。

PCSはcommit作成時には成立しない

RFC 9420は、Update proposalだけではpost-compromise securityにならず、他のmemberがCommitへ取り込み処理して初めて効力を持つと明記する。forward secrecyには古い秘密鍵と使用済みmessage keyの削除も必要だ。

CURRENT案ではMLS exporterの秘密をTLS record保護へ渡し、in-band commitでepochを進める。認証済み確認は相手が新状態を知る証拠になる。それでも、旧コピーが全て消えたこと、攻撃者が端末を失ったこと、identityが有効なこと、アプリケーションが継続したことまでは証明しない。

「PCS対応」は設計能力の名称であり、侵害窓が閉じた時刻の領収書ではない。

衝突と再開は別の履歴を作る

両者が同時に更新すると、草案は初期roleで衝突を解く。一方は競合commitを無視し、もう一方は自分のpending commitを捨てて相手のものを処理する。収束しても、ローカル履歴は同じではない。

接続再開時にはpending commitを再送できる。既に適用した同一commitを二重適用してはならない。接続断の検出自体はprofileの範囲外でtransportに依存する。最終epoch番号だけを残す監査では、通常確認、衝突、再送、再開を区別できず、旧材料がいつまで残ったかも追えない。

八つの受領証

Lu HengのMinimum Initial Specificationは、共通層を決定論的なmessageとstate transitionに限定する。Running-Code Primacyは、名称や会議状態ではなく端末が実際に検証・導入・削除した事実を優先する。現実の層として、更新作成、commit送信、相手の認証、相手の適用、確認返送、開始側の導入、旧材料削除、新epochで最初に認証されたapplication recordを分けるべきだ。

草案自身も未完成性を示す。完全なsecurity analysis、cross-protocol分離、message framingの一部はTODOである。BoFは課題を発見できるが、完成や合意を宣言する場所ではない。

出典と限界

これらはcharter済みWG、IETF合意、採択済みWG draft、RFC、完成した安全性分析、相互接続、展開、測定済み侵害回復、PQC運用、incident、service結果を証明しない。