要約

  • 7月の00版には、開始側のID_CRED_Iを第1メッセージに平文で載せ、第5メッセージを省く案があった。草案は開始側の身元秘匿を失うと明記していたが、9月28日の01版にはその節がない。
  • 現行案は5通を必須とする。応答側が開始側を認証し、アプリケーション鍵を導出できるのは、第5メッセージを検証してからである。
  • 方法番号の「5」は提案値にすぎない。KEM方式という名称だけでは耐量子性は確定せず、実際に選ぶKEMと暗号スイートが条件になる。

今回の変更を「握手が5通に増えた」と書くのは不正確だ。主たる5通の流れは7月の版にもあった。変わったのは、4通で済ませる別案が9月版からなくなった点である。00版の第6.3節は、開始側の資格情報識別子をmessage_1で明かせば、応答側が必要な静的鍵の情報を早く得て、最後のメッセージを省けると説明していた。同時に開始側の身元を守れなくなるとも明記していた。これは草案上の選択肢であり、実際の漏えいや採用実績ではない。

01版の第3節は、message_1からmessage_5_KEMまでを必須の5通として列挙する。削除から編集者の理由を断定することはできないし、4通のKEM方式が数学的に不可能だと証明されたわけでもない。ただ、今の作業部会文書に、身元秘匿を弱めて1通節約する案が書かれていないことは確認できる。設計比較では、存在しない現行オプションを前提にしないことが第一歩となる。

KEMでは、静的秘密鍵の保有者が自分の公開鍵に対するカプセル化暗号文を受け取ってからでないと、その秘密鍵を持つことを示せない。この依存関係について、草案は最大で1往復の追加を見込む。第4メッセージは応答側の鍵確認を、第5メッセージは開始側の鍵確認を担う。開始側は第4通を処理して第5通を作成した後にアプリケーション鍵を導出できる一方、応答側は第5通を検証するまで待つ。片方が次へ進める時点を、そのまま相手側の認証完了時点にしてはいけない。

それ以前にも境界がある。開始側は第3通で自身の暗号化された資格情報を渡す前に、応答側の資格情報をローカルな信頼方針で検証し、受け入れなければならない。これは00版にもあった要件で、新たな安全機能ではない。署名や形式が正しい相手でも、接続を望んだ相手とは限らないためだ。暗号化による秘匿、相手の受け入れ、双方向の最終認証を一つのチェック欄にまとめるべきではない。

レジストリ提案の範囲も縮んだ。00版はCOSEのML-KEMアルゴリズム値、EDHOCの暗号スイート値、認証方法の値を提案した。01版のIANA節は方法タイプの提案値「5」のみを掲げ、量子耐性スイートやKEMの表現は別の作業文書を参照する。提案値は割当済み番号ではなく、参照先も承認済みの規格ではない。さらに方法自体は特定のKEMに依存しないと明記されている。耐量子性を論じるなら、実際に採用するアルゴリズムまで確かめる必要がある。

機器の更新を考える運用者には、通数の比較だけでは足りない。資格情報の開示時点、選択したスイート、第5通が届かない場合の状態、両端が「完了」と記録する条件を別々に試すべきだ。これはDaniel Kadeによる評価上の提案であり、IETFが新たな監査帳票を義務付けたという意味ではない。作業部会草案から、現場での導入率や攻撃事例は読み取れない。

出典