要約

  • IESGは2026年9月3日、draft-ietf-tls-mlkem-10をInformational RFCとして公開することを承認した。ML-KEM-512、768、1024をTLS 1.3の独立したNamedGroupとして定義するが、確認時点ではRFC番号は未割当だった。
  • 三つの行はDTLS-OK=Y、Recommended=Nである。RFC 9847のNは欠陥や禁止を意味せず、IETFが適合性を推奨していない状態を表す。

運用会議で「IETF承認済み」という一行だけが資料に残れば、次の週には既定設定へ入るかもしれない。別の会議でRecommended=Nだけが切り出されれば、永久禁止になるかもしれない。どちらも公式記録の半分しか読んでいない。

第10版はワイヤ上の役割を明確にする。KeyGenが公開カプセル化鍵と秘密復号鍵を作る。クライアントは公開鍵をClientHelloのkey_shareに置く。サーバはEncapsでciphertextと共有秘密を作り、ciphertextをServerHelloに返す。クライアントはDecapsし、同じ32バイトの秘密をTLS 1.3の鍵スケジュールへ渡す。

NamedGroup値は512、513、514である。公開鍵とciphertextの大きさは、ML-KEM-512で800/768バイト、768で1,184/1,088バイト、1024で1,568/1,568バイトとなる。この数字だけから遅延、分割、再送、装置容量を断定してはならない。

サーバはFIPS 203の公開鍵検査を実行し、失敗すればillegal_parameterで終了する。クライアントも選択されたパラメータとciphertext長が合わなければ同じ警告を出す。それ以外の復号失敗はinternal_errorになる。key shareはtranscriptに含まれ、鍵とciphertextがハンドシェイクへ結び付く。

しかし実装の境界は残る。ciphertext生成の乱数とciphertext自体は再利用禁止である。秘密鍵を持つ相手はカプセル化乱数を正確に回復するため、弱い乱数生成器が他の出力や内部状態との関係を漏らす場合、その情報も相手へ渡る。FIPS 203やNIST SP 800-227、RFC 8937は指針であり、特定ビルドの証明書ではない。

9月5日のIANA表には三方式がすでに載っていたが、参照先は以前の個人草案第05版だった。Datatracker側は第10版の承認公告送信済み、IANA作業中を示していた。これは更新途中の時点観測であり、恒久的な不整合とは言えない。スクリーンショットではなく時刻付きデータとして保存し、後で再確認すべきだ。

RFC 9847はRecommendedを三分する。Yは定義された目的に適するというIETF合意、Dは理由付きの非推奨、Nは適合性についてIETFの判断がない状態である。限定用途や条件付き利用、合意不在を含み得るが、欠陥認定ではない。

隣のDTLS-OK=YはDTLSで使えるかという別軸だ。製品品質や組織の採用判断を表さない。二列を一つの緑色アイコンへ変換すれば、UIが存在しない推奨を作ってしまう。

RFC 10024のハイブリッド群を見ると、X25519MLKEM768は現在Y、他のいくつかはNである。純粋ML-KEM文書は、純粋方式かハイブリッドかを安全性、性能、運用制約で評価するよう求める。登録番号はその評価を代行しない。

導入証拠は、文書版、IANAスナップショット、ライブラリと暗号モジュール、RNGとreseed、終端ごとの設定、ClientHelloのoffer、ServerHelloのselection、検査エラー、完了handshake、アプリ応答の順で残す。設定は通信ではなく、offerはselectionではなく、handshakeはサービス成功でも権限でもない。

Lu Hengの最小初期仕様は、共通形式を弱くする議論ではない。共通部分を番号、バイト、検査、失敗動作へ集中させ、将来の採用判断を影響を負う現場へ残す。running codeと現実層の考え方は、公式文書を実測の代用品にしない。

IESGは三方式を説明可能にした。IANAは調整可能にした。Nは、その二つが一般推奨まで行っていないことを明示した。次の行為には、組織自身の署名が必要になる。

情報源