Content is user-generated and unverified.

IETF 125 TLS WG 議論まとめ

会議: IETF 125（2026年3月16日〜20日、深圳） セッション: 月曜日（1時間）、金曜日（2時間） 参加者: 約120名 議長: Sean Turner、Joe Saloway、Deirdre Connolly（リモート） ソース: 議事録ノート、プレゼンテーションスライド、録画文字起こし

1. WGステータスとアップデート

公開されたRFC

以下の4つのRFCが正式公開された。

RFC 9847 — TLS/DTLSのIANAレジストリ更新
RFC 9849 — TLS Encrypted Client Hello
RFC 9848 — DNS Service BindingsによるECHブートストラップ
RFC 9853 — DTLS 1.2/1.3のReturn Routability Check

ドキュメントステータス

RFC Editorキューにある文書として、rfc8446bis、rfc8773bis、hybrid-design、tls12-frozen、keylog-file、tls13-pkcs1、deprecate-obsolete-kexの計7本がある。

WG Last Call中のドキュメントは2つで、super-jumbo-record-limit（2実装あり、ただし両方ともHannes Tschofenigが関与しており独立性に懸念）と、ml-kem（後述の通り議論継続中）。

実装経験が必要なドラフトとして、key-share-prediction、tlsflags、wkechがある。

ML-KEMに関する苦情・アピール

ML-KEMのWG採択に対する異議申し立ては却下され、引き続きWGドラフトとして扱われることが確認された。DJBに対するモデレーション措置はIESGによりRFC 3934に準拠していると確認されたが、議長側のmailmanの操作ミスにより、モデレーション期間が予定より4〜5日（最大1週間近く）長く維持されてしまったことについて謝罪があった。

8446bisの鍵再利用禁止

金曜セッションで、エフェメラル鍵の再利用をRFC 8446bisで明確に禁止する動きが報告された。現在のAppendix Cの「SHOULD NOT」を本文に移して強化するPRがEric Rescorlaから提出済みで、月曜日に正式なコンセンサスコールを出す予定。

IEEE連絡声明

IEEE 802.1aeの作業グループから、純粋ML-KEM文書のRFC公開を支持するリエゾンステートメントが届いたことが報告された。

2. ML-DSA in TLS 1.3 — draft-ietf-tls-mldsa-01

発表者: Tim Hollebeek ドラフト: draft-ietf-tls-mldsa

概要

FIPS 204で定義された3つのML-DSAサイズをTLS 1.3のコードポイントとして登録する非常にシンプルなドラフト。TLS 1.2での使用は禁止。ハイブリッドはスコープ外。著者はWGLCを要請した。

主な議論

Richard Barnes がコードポイントは既に登録済みでFIPSを参照すれば十分ではないかと疑問を呈した。
David Benjamin が「RFCがないとIETFを密にフォローしていない実装者に伝わらない」と反論し、TLS 1.2禁止の明記、コンテキスト文字列の指定、プレハッシュ形式の選択など、FIPS単体では規定できない事項がある点を指摘した。
Victor Dukhovni がTLS 1.2での証明書チェーンにおけるML-DSA使用（検証側）は許可されるべきかという技術的問題を提起。
Eric Rescorla がsignature_algorithmsの広告メッセージと実際の使用の区別について精密な規定が必要だと指摘し、テキスト作成を協力すると申し出た。
John Mattsson は「完璧でWGLC準備OK」と支持。
Usama は不要だと反対したが、大勢は公開に賛成。

決定

WGLCの前に既知のイシュー（特にTLS 1.2との技術的境界に関するテキスト）を解決するリストを作成する。

3. TLS PAKE — draft-ietf-tls-pake-01

発表者: Laura Bauman（リモート） ドラフト: draft-ietf-tls-pake

概要

パスワード認証鍵交換（PAKE）のTLS 1.3拡張仕様。IETF 124以降、多くのイシューが解消された。CPACEの使用仕様追加、マイナーな明確化を含む新バージョン01が公開済み。

主な議論

Scott Fluhrer がSPAKE2+のセキュリティ考慮事項を指摘：低速な量子コンピュータでも離散対数問題を1つ解ければシステムを破壊できるという性質があり、これをSecurity Considerationsに記載する必要があるとした。
Usama/Dennis Jackson がTLS Finishedメッセージによる明示的鍵確認の代替について、ProVerif等の形式解析が不可欠だと主張。著者もProVerifモデルの拡張作業を進行中と報告した。ただし、Usamaの指摘する性質がProVerifで直接検証可能かどうかについて疑問も呈された。
Eric Rescorla はFATプロセスよりもメリットそのものが重要であり、「かなり大きな変更なので実質的な解析なしには進められない」と述べた。
Tom Dowling（FAT）がFATはゲートキーパーではなく助言的役割であることを強調し、FATが議論の道具として利用されることへの懸念を表明した。

決定

議長が著者とフォローアップし、次のステップを決定する。WGLCの前に形式解析の結果が必要となる可能性が高い。

4. ML-KEM for TLS 1.3 — draft-ietf-tls-mlkem-07+

発表者: Deirdre Connolly ドラフト: draft-ietf-tls-mlkem

概要

ポスト量子暗号のML-KEMをTLS 1.3で単独（ハイブリッドなしの純粋PQ）の鍵合意として利用するための仕様。draft-ietf-tls-hybrid-designと対をなす形で、ハイブリッド不要なユースケース向け。CNSA 2.0準拠のためのML-KEM-1024もサポートする。

2回目のWGLC後の主な変更

参照の追加
Motivationセクションの複数回改訂
8446bisとの重複構造の削除
乱数再利用禁止（MUST NOT）規定のSecurity Considerationsから本文への移動（規範的変更）
ハイブリッドが好まれる理由の言語追加
KEMのセキュリティ分析への複数参照追加

WGLCの結果と今後

議長のSean Turnerは、198〜235通のメッセージを精査した結果、以下の3点を解決しないとコンセンサスが得られないと判断したことを報告した。

鍵再利用に関するテキスト — 8446bisでの禁止強化と連動
ハイブリッドを選好する理由のテキスト — Security Considerationsの書き方
モチベーションセクションの扱い — 削除するか、リスクベースに書き換えるか

これらの変更後にターゲットコンセンサスコールを実施する予定。

主な議論（月曜セッション）

Deirdre がMotivationセクション自体の削除を提案。
Victor Dukhovni はリスクを中立的に提示する形への書き換えを提案。
Usama はハイブリッドから純粋ML-KEMへの移行は「セキュリティの劣化」（2つの困難な問題から1つに減る）だと強く反対。Deirdreは「TLSには複数の鍵合意手法がある。RSAベースからECDHへの移行が劣化でないのと同様」と強く反論。
John Mattsson は「MUST NOT reuse randomness」と8446bisの「SHOULD」の関係に懸念を示しつつ、静的鍵のプライバシー面への言及不足を指摘。NIST 800-227の要件との整合性説明も求めた。

主な議論（金曜セッション）

Eric Rescorla がWGLCの結論を明示すべきと要求。反対者の数だけでコンセンサスバーを越えられるのかと問うたのに対し、議長は「越えられると考える」と回答。
Tanja は新しいPQシステムを唯一のセキュリティ保証として採用することへの慎重論を展開。
John Mattsson は8446bisで鍵再利用を禁止すれば自分の懸念はほぼ解消すると述べた。
Victor はSecurity Considerationsの書き方について、「proponents of hybrid」という対立的フレーミングを避け、リスクを中立的に提示すべきだと提案。
Tom Dowling（FAT）はFATがKEMの暗号プリミティブのセキュリティを評価する役割ではない（それはNISTの仕事）と明言しつつ、プロトコルレベルの計算論的安全性解析はFATのスコープ内だと説明。
Victor はOpenSSLが純粋ML-KEMをサポート済み（デフォルトOFF）であり、このドラフトの可否に関わらず使われ続ける現実を指摘。

5. PQC Continuity — draft-sheffer-tls-pqc-continuity-01

発表者: Yaron Sheffer ドラフト: draft-sheffer-tls-pqc-continuity

概要

PQCへの移行期間にTLSサーバーがダウングレード攻撃から保護されるためのTOFU（Trust On First Use）型の仕組み。サーバーが「一定期間PQC証明書を提供する」とコミットメントを送り、クライアントがそれをキャッシュすることで、PQC証明書が送られてこない場合に中間者攻撃を検出できる。HSTSのTLSレイヤー版に相当し、PKIの変更は不要。

主な議論

クライアント証明書のサポートについてはEric Rescorlaがメーリングリスト上で問題を提起しており、現時点ではサーバー証明書のみに限定。
CDN環境では全POP（Point of Presence）がPQC証明書を提供できることを確認するまでコミットメントを送るべきではない。
ミドルボックスはコミットメントを送信・転送すべきではない。
Eric Rescorla が実装に興味ある人がいるかと尋ねたが、マイクに立つ人はおらず、まだ時期尚早という雰囲気だった。

決定

メーリングリスト上で継続議論。

6. Extended Key Update (EKU) — draft-ietf-tls-extended-key-update-10

発表者: Yaroslav Rosomakho（著者）、Tom Dowling（FATレポート） ドラフト: draft-ietf-tls-extended-key-update 金曜セッションで最も長い時間が割かれたトピック

FATレポート — Tom Dowling

Tom Dowlingが約30分かけてFATの分析結果を報告した。

通常のKey UpdateとEKUの違い： 通常のKey Updateは既存の安全性証明の延長線上で比較的簡単に扱える（KDFで新しい鍵を導出するだけで、攻撃者はプロセスに介入できない）。一方、EKUでは新たなエフェメラル鍵交換を行うため、Post-Compromise Security（PCS）の証明は根本的に異なる課題を提起する。以前のセッションキーを攻撃者に渡す前提で安全性を議論する必要があり、悪意あるEKUメッセージへの対処やモデルの再構築が必要。

transcript hashの問題（修正済み）： 以前のバージョンでは、EKUで新しい秘密を導出する際にハンドシェイクのトランスクリプト全体ではなくEKUメッセージのみを使っていたため、TLS 1.3の鍵スケジュールとの連携が切れる可能性があった。FATの指摘を受けて修正され、rolling transcriptが導入された。

セッションチケットの問題： EKU実行後に古いセッションチケットを破棄しないと、攻撃者が古い鍵状態にロールバックできてしまう。著者はこの点を文書に反映済みだが、サーバーがステートレスであるため実装上の課題がある。

関連研究の限界： Signalの継続的鍵合意やIKEv2のcreate_child_sa再鍵には類似メカニズムがあるが、いずれもEKUに適用可能な既存の解析がない。

FATの結論：

慎重な解析が必要
既存のTLS 1.3解析を容易に拡張できない
記号的・計算論的解析いずれも有益
FAT自体は安全性証明を行う義務はなく、あくまで助言的役割
フレームウォーに巻き込まれることへの懸念を表明

著者のプレゼンテーション — Yaroslav Rosomakho

-06以降の主な更新：

用語の整理： 「long-term secrets」→「TLS main secret」、「traffic secrets」→「traffic keys」
フロー簡略化： David Benjaminの提案により、レスポンダが応答送信直後に送信鍵を更新する方式に変更。TLS/DTLSともにメッセージ往復が削減。
トランスクリプトハッシュの改善： FATのフィードバックに基づき、前回のトランスクリプトをDerive-Secretに混入。transcript_hash_0はClientHelloからClient Finishedまでの元のTLSハンドシェイクトランスクリプト。
Exporterの考慮事項更新： 初期exporter secretはEKUで更新されない。EKUにより新しいexporter secretが生成される。(D)TLSライブラリがアプリケーションにexporterローテーションを通知する必要がある。
Post-Handshake Authentication（PHA）との衝突対処： EKUがPHA進行中に開始された場合、EKUが先に完了する必要がある。
セッション再開への影響の明確化： EKU前に取得されたPSKが侵害された場合の対策として、再開の無効化、セキュアストレージ/分離によるPSK保護、EKU後の古いチケット無効化。
非形式的セキュリティ目標の追加： Post-Compromise Security、鍵の新鮮性（暗号学的独立性）、標準Key Updateの排除、鍵状態の乖離検出。

実装状況： rustlsとmbedTLSの2つのプロトタイプ実装が存在し、相互運用も確認されている。POMELA/SPINモデルもGitHubリポジトリに追加済み。

オープンイシューの議論

#94 強化PCS（必須再認証）：

Eric Rescorla は「必須にする必要はない。Security Considerationsで影響を議論し、オプションとして残せば十分」と述べた。
John Mattsson は「必須ではないが、組み込みの再認証機能自体は追加すべき。でないとアプリケーション層の変更が必要になる」と指摘。NISの要件ではIPsecで数時間後にDH再交換、24時間後に再認証が求められるとの例を挙げた。
著者はこの問題を将来の作業に委ねることを提案。

#100 TEEの脅威モデル：

Usama は「TEEで秘密鍵のみ保護し、アプリケーショントラフィックキーはOS上に露出する構成は意味がない」と主張。
Eric Rescorla は「TEEの議論はレッドヘリング。テキストの1語であり、編集作業で解決可能」と述べた。TEEは署名オラクルとして機能するケースがあり、それ自体は妥当だと補足。
Tom Dowling も「TEEはプロトコルの安全性モデルとは無関係」と述べた。
Felix Linker がSPIN/Promelaモデルで何を評価したかを質問。Hannes Tschofenigが、David Benjaminからのコメントを受けて、特にDTLS 1.3でのメッセージロスを伴う複数のpostハンドシェイク認証メッセージのデッドロック検出に焦点を当てたと回答。

7. TLS 1.3ハンドシェイクの64K制限超え — draft-wagner-tls-keysharepqc-08

発表者: Valery Smyslov ドラフト: draft-wagner-tls-keysharepqc

概要

TLS 1.3ではハンドシェイクメッセージのサイズが2^24バイト、拡張フィールドが2^16-1バイトに制限されている。一部のPQ KEMの公開鍵はkey_shareに収まらない可能性がある。発表者は冒頭で「必要かどうかではなく、どう実装するかに集中してほしい」と明確に述べた。

3つの提案の比較

Proposal 1 — CH/SHフォーマット変更： 拡張サイズを拡大し新しいPQ用key share拡張を定義する方式。シンプルで追加ラウンドトリップなし。しかし後方互換性がなく、ECHやミドルボックスとの相互作用が不明。OpenSSLフォークによるPoC実装あり。

Proposal 2 — Extended Key Update活用： John Ladsonが提案。ハンドシェイク後にEKUで追加鍵交換を行い、常にハイブリッド・非複合化する方式（IKEv2類似）。TLSハンドシェイクメッセージの変更不要でミドルボックス問題なし、後方互換性あり。しかしステートマシンが複雑化し、アプリケーションデータの送信が遅延する。

Proposal 3 — 新規AuxHandshakeDataメッセージ： CH/SHに続く新しいハンドシェイクメッセージにラージデータのチャンクを格納し、CH/SHから参照する方式。汎用的な解決策（key share以外にも適用可能）、CH/SH変更なし、後方互換性あり。しかしHRRが常に必要になるという欠点あり。

主な議論

Yaroslav Rosomakho はポストハンドシェイクでEKUを使うアプローチが最も互換性が高いと意見を述べた。
Eric Rescorla が「興味深い知的問題だが、実際の動機（巨大PQアルゴリズム）がまだ存在しない。WGの時間を使うべきではない」と明確に反対。マイクに立って作業を支持する参加者はいなかった。
この問題は元々ISCからTLS WGに送られたものであることが議長から説明された。

8. FATプロセスの改善提案

発表者: Muhammad Usama Sardar

提案内容

著者向けベストプラクティステンプレート： 動機、脅威モデル、非形式的セキュリティ目標、プロトコル図、鍵スケジュール図を含む統一的なドキュメント構造を提案。
FATトラッキングの透明性向上： ダッシュボードの作成を提案。各ドキュメントについて、FAT担当者の割り当て、コンセンサスコールメール、初期レポートの状態が一覧できるようにする。Usama自身がメンテナンスをボランティアで行うと申し出た。
「控えめな」提案： プロセスの透明性向上、FATレビューが論争的なドラフトの解決に役立つ可能性、著者からの積極的な関与の要請。
「控えめでない」提案： 他のWG（例：STREET WG）がTLSプロトコルに大きな変更を加える場合のTLS WGとの早期協議プロセスの義務化。FATへの直接連絡制限の撤廃。

主な議論

Eric Rescorla は「透明性部分は良いが、『verifier』という特別な役割の構築は不適切。FATへの連絡は開かれるべきだが、特定の人だけがアクセスできる仕組みは逆効果。他のWGへの義務化もTLSの負担を増やすだけ」と指摘。
Felix Linker はFAT呼び出しにはWGコンセンサスが適切な基準であると提案。
Tom Dowling は計算論的安全性解析もFATのスコープ内であると明言（暗号プリミティブの解析は除く）。

9. ECH計測報告

発表者: 名前不明（Defo team関連）

DNS性能テスト

Tranco上位10,000ドメインに対してA/AAAA/HTTPSリソースレコードの応答時間を計測した結果、HTTPSリソースレコードは60%のケースでHappy Eyeballs V2ベースラインと同等以上の速度だった。50ms以上遅延したのは6%、100ms以上は3%のみ。QUIC対応ドメインではさらに良好で、1ラウンドトリップの削減効果がある。

HTTPSリソースレコードが実質的なペナルティとなるのは、他のレコードよりもTCPハンドシェイク分以上遅い場合のみ。

ECH GREASEテスト

上位10,000ドメインでECH GREASEを有効にしてテストした結果、コネクティビティの破壊は確認されなかった。一部のドメインで異なるハンドシェイク時間が観測されたが、再試行で全て成功。

ネットワークテスト

Socksプロキシネットワークを使用し、各国の878のモバイルネットワークでwww.google.comへのアクセスをテスト。ECH GREASEで失敗したのはわずか3ネットワーク（0.34%）。22.9%のネットワークではコントロール・実験の両方が失敗（プロキシの不安定性やレート制限が原因）。中国ではgoogle.comのブロッキングによりテスト不可だが、ECH自体はブロックされていない。

問題点

米国.govドメインの一部がHTTPSリソースレコードに応答しない（タイムアウト）という深刻な問題が報告された。Eric RescorlaがCISAの連絡先リストを使って個人的にドメイン管理者へ連絡を試みると申し出た。Victor DukhovniがCISAリポジトリの連絡先情報をチャットに共有し、RIPEのAtlasネットワークを使ったより広範なDNS計測を推奨した。

結論

ネットワーキングライブラリでHTTPSリソースレコードとECHをデフォルト有効にすることは可能だが、応答しないドメインに対するHTTPSレコード待機のキャッピングが当面必要。

10. Signed ECH Configs — draft-sullivan-tls-signed-ech-updates-00

発表者: Dennis Jackson ドラフト: draft-sullivan-tls-signed-ech-updates

概要

ECHのデプロイを簡易化する提案。従来のECHではリトライ時に外部SNI用のドメイン登録とTLS証明書取得が必要だが、この提案では署名用公開鍵のハッシュをDNSレコードに格納し、リトライ時にサーバーがその公開鍵で署名した新しいECH configを返すことで認証する。これにより、外部SNIにランダム文字列を使用することが可能となる。

メリット

デプロイの容易さ： Caddy等のTLSサーバーが追加設定なしでECHをデフォルト有効化可能。
CDN側の改善： 顧客のドメインが他のサイトと共有されないため、ECH導入への抵抗が減る。
ブロッキング耐性の向上： 固定SNIのブロックリスト追加は容易だが、ランダムSNIの検出は（アクティブプローブやIP-ドメインマッピングのスキャンが必要となり）コストが高い。

主な議論

Yaroslav Rosomakho はランダムSNIがDNS解決不能になる場合のクラウドサービス・プロキシへの影響を懸念。完全にランダムな文字列は解決可能な文字列にすべきとのガイダンスが必要と指摘。
Eric Rescorla はECHの認証されていないSNI送信によるプライバシーへの懸念を表明しつつ、フラジリティ改善の議論は評価。サーバーがECH configをインラインで提供する方式との組み合わせを示唆。
今後、raw public keysベースのアプローチに絞る方向で簡素化予定（証明書ベースのメカニズムは削除）。

11. Workload Identifier Origin Hint — draft-rosomakho-tls-wimse-cert-hint-02

発表者: Yaroslav Rosomakho ドラフト: draft-rosomakho-tls-wimse-cert-hint

概要

ワークロード環境でのmTLS使用を改善する提案。従来、mTLSを使いたいサービスはmTLS専用のエンドポイント（別SNI）を用意する必要があった。この提案では、ClientHelloにワークロードIDのオリジンヒントを含める拡張を追加し、クライアントがcertificate requestに対応可能であることと、保持する証明書の信頼ドメインをサーバーに伝える。

主な議論

Eric Rescorla はクライアントが最初のメッセージで身元を示す必要性に疑問を呈しつつも、ECHとの組み合わせやサーバー側からのECH config提供による解決策を示唆。プライバシー面でネットワーク上のクリアテキストでの情報露出への懸念を表明。
Dennis Jackson はTLSフラグで「クライアントがcertificate requestに対応可能」と示し、信頼ドメイン情報はcertificate request側に入れるアプローチを提案。
Thiru はtrust anchor IDsとの補完やKubernetes等の管理環境でのECH設定配布の可能性を指摘。

全体の傾向と今後の方向性

IETF 125のTLS WGでは以下が主要テーマだった。

ポスト量子暗号の標準化推進： ML-DSA（WGLC準備中）、ML-KEM（コンセンサス形成に向けた課題解決中）、ML-KEMの鍵再利用禁止の強化。
Extended Key Updateの成熟： FATからの形式解析フィードバックを反映した設計改善、実装の進展。形式的安全性証明はまだ完了していないが、著者とFATの建設的な協力関係が構築されている。
ECHの実運用展開： 計測データに基づくデフォルト有効化の可能性確認、Signed ECH Configsによるデプロイ簡易化。
PQ鍵サイズ増大への対処： 64K制限超えの設計検討は知的に興味深いが、現時点ではWGの優先事項ではないという合意。
FATプロセスの改善： 透明性向上のダッシュボード構想は支持されたが、特別な役割の構築やアクセス制限の追加には反対意見。

Content is user-generated and unverified.