【参加報告】IETF124 TLS WG セッション1

Posted at 2025-11-05

こんにちは！
GMOコネクトの菅野哲（かんのさとる）でございます。
みんな、IETF124が開催されていますが、いかがお過ごしでしょうか？

今回のIETF124では、みんな大好きTLS WGのセッションが2つ開催されるのですが、まずは初回の方をまとめます。

はじめに

2025年11月3日、カナダ・モントリオールで開催されたIETF 124において、TLS (Transport Layer Security) WGのセッション1が行われました。本記事では、PQC (Post-Quantum Cryptography) への移行、鍵更新メカニズムの強化、新しい認証方式など、TLSプロトコルの最新動向について報告します。
今回は特に、ML-KEM と SLH-DSA を巡る Complaint/Appeal（不服申し立て）の背景がセッション全体の前提になっていたため、その経緯も含めて整理します。

セッション動画: IETF 124 TLS Session 1

1. WGの現状と重要な決定事項

概要

TLS WGセッションは、まずWGステータスの共有から始まりました。ここでの主なトピックは、

ECDHE-ML-KEM ドラフトに含まれる「Kyber実験コードポイント」の扱い
ML-KEM / SLH-DSA を巡る Complaint / Appeal（不服申し立て）の結果

の確認です。

この背景を押さえておくと、その後のドラフト議論の意味が理解しやすくなるため、少し丁寧に整理します。

1.1 IETFにおける Complaint / Appeal（不服申し立て）とは

IETF では、ドラフトのライフサイクルの各段階（例：WG採用、WGLC、IESGレビュー等）で、

手続きや判断に対して異議を唱える仕組みとして
- Complaint（苦情・異議申し立て）
- Appeal（正式な不服申し立て）

が用意されています。

典型的には、

「WGとして採用すべきでないのに採用されたのではないか」
「AD / IESG の判断がIETFプロセスに反しているのではないか」

といった疑義に対して、
プロセスの妥当性を第三者的に検証するためのメカニズムです。

TLS WGのステータススライドでは、今回のPQC関連ドラフトについて、

ML-KEM: Complaint was unsuccessful and I-D is still an adopted WG draft
SLH-DSA: Appeal was success and I-D is not a WG draft

と明示されており、ML-KEM と SLH-DSA で「明暗」が分かれた形になっています。

1.2 ML-KEM に対する Complaint の背景と結果

1.2.1 争点：なぜ「ML-KEM only」Draft が必要なのか？

ML-KEM については、すでに ハイブリッド鍵交換を定義する draft-ietf-tls-hybrid-design（ECDHE + ML-KEM）が進んでいるにもかかわらず、さらに 「ML-KEM only」をTLSで使うためのドラフト draft-ietf-tls-mlkemを WG アイテムとして進める必要があるのか？という点が争点になっていました。

反対する側の主な論点は、ざっくり以下のようなものです。

ハイブリッドドラフトには明確なモチベーションがある一方で、ML-KEM only ドラフトは「なぜ今必要か」の説明が弱いのではないか
2つのドラフトを並行して標準化することによる実装・運用・レビューのコスト増が無視されていないか

こうした問題意識から、WG採用に対する Complaint / Appeal が AD に対して正式に提出されました。

1.2.2 結果：Complaint は退けられ、WGドラフトとして継続

ADによる評価の結果、

WGでの採用プロセス自体は手続き的に正しく行われていること
「ML-KEM only も必要だ」という側の技術的主張にも一定の妥当性があること

が確認され、Complaint / Appeal は退けられました。

その結果、

ML-KEM Internet-Draftは引き続き WG 採用ドラフトとして継続
実装状況（BoringSSL, OpenSSL, s2n, Rustlsなど）も揃いつつあり、WGLCに進める方向で議論が進行

というステータスになっています。

本報告書の後半（2.4 ML-KEM only）で述べるとおり、

「Recommended 値を D に下げるべきでは」という提案は却下し、WGLCに進める

という形で、TLS WGとしてはML-KEMをTLSの中核PQCオプションとして前に進める方針が明確になりました。

1.3 ECDHE-ML-KEM と Kyber実験コードポイントの整理

（補足）コードポイントとは？

TLS では、Ciphersuite・サポートグループ・署名アルゴリズム・拡張タイプなど、さまざまな要素が 「コードポイント（数値ID）」 で識別されます。

例：Ciphersuite TLS_AES_128_GCM_SHA256 → 0x1301
例：サポートグループ x25519 → 0x001D

これらの番号は、IANA が公開している「TLS パラメータレジストリ」で一元管理されており、

どの番号がどのアルゴリズムに対応しているか
そのアルゴリズムが推奨かどうか（Recommended / D = Discouraged）

といった情報が整理されています。

PQC などの新しいアルゴリズムを試すときには、標準化前から

「とりあえずこの番号を 実験用コードポイント として使おう」

という形で番号が割り当てられることがあります。
今回問題になっている X25519Kyber768Draft00 などは、ドラフト版 Kyber を試すためだけに使われていた一時的な番号だと思っておくとイメージしやすいです。

標準化が進んだ現在では、

こうした古い実験コードポイントがそのまま残っていると、
- 新しい正式な ML-KEM と混同されたり
- 過去の実験実装が誤って本番で使われ続けたり
というリスクがあるため、IANA レジストリ上で 「D（Discouraged）」として明示的に封じる ことが重要になります。

以下は、その整理をどの文書でどう行うかを TLS WG として決めた、という話なのです。

1.3.1 論点：実験コードポイントをどう「廃止」するか

draft-ietf-tls-hybrid-design（ECDHE-ML-KEM）では、過去の Kyber 実験実装で用いられていたコードポイント（X25519Kyber768Draft00、SecP256r1Kyber768Draft00 など）を、IANAレジストリ上で 「D（Discouraged）」としてマークする ことを提案しています。

この処理をどのような経路で行うかについて、以下の2案が提示されました。

現在の Internet-Draft をそのまま Standards Track に移行し、
Kyber 実験コードポイントを D にマークするテキストも同一文書内に保持する
実験コードポイントの廃止だけを目的とした短い別文書を新規作成し、
現行ドラフトからは当該テキストを取り除く

1.3.2 Meetecho Poll によるコンセンサス確認

この点については、セッション中に Meetecho の Poll 機能を用いてコンセンサス確認が行われました。

Poll「Obsolete Code Points」の結果は以下の通りです。

Present when poll closed: 104（投票締め切り時点でセッションに参加していた人数）
Yes: 37 (71%)
No: 0 (0%)
No Opinion: 15 (29%)

この Poll 結果と、会場での議論を踏まえ、Chairは

オプション1（現行ドラフトを Standards Track に移行し、同じ文書内で Kyber 実験コードポイントを D マークする）を採用する
メーリングリストでもう一度確認したうえで、Standards Track 版に対して 1 週間の WGLC をかける

という方針を確認しました。

PQCまわりの実験的コードポイントについても「とりあえず放置」ではなく、きちんと標準文書の中で整理していくというTLS WGの姿勢が、Pollの数字とともに明確に示されたと思います。

1.4 SLH-DSA に対する Appeal の背景と結果

ML-KEMとは対照的に、SLH-DSA（SPHINCS+由来のハッシュベース署名） をTLSでどう扱うかについては、最終的に Appeal が認められ、WGアイテムではなくなるという結果になりました。

1.4.1 ドラフトの内容と懸念点

対象となったのは、概ね次のような内容のドラフトです。

ドラフト：TLS 1.3 で SLH-DSA を署名スキームとして扱うための仕様
モチベーション：
- SLH-DSA はハッシュベースで保守的な安全性を持つ
- 「万が一、格子ベース署名に新たな脆弱性が見つかった場合」のバックアップとして意味がある

一方で、SLH-DSAには次のようなデメリットがあります。

署名サイズ・検証コストともにML-DSAよりかなり重い
TLSハンドシェイクに組み込むと、ハンドシェイクサイズの肥大化・レイテンシ増大が懸念される

TLSのような遅延に敏感なプロトコルに組み込むには、運用面でかなり重い選択肢です。

1.4.2 Adoption Call → 反対意見 → Appeal

TLS WG では、このドラフトについて 2 回目の WG Adoption Call まで行われましたが、メーリングリスト上では次のような反対意見・懸念が多く出ました。

「NISTが標準化した全てのPQC署名をTLSに入れる」という方針は、実装・運用コストを無視していないか
すでに ML-DSA ドラフトも進んでいるのに、性能コストの大きい SLH-DSA までTLSで標準化する必要が本当にあるのか
ハンドシェイクサイズ・CPU負荷の観点から、実運用に耐えにくいのではないか

最終的に、WGチェアの判断（採用に前向き）に対して正式なAppealが提出され、ADがIETFプロセスの観点から評価することになりました。

1.4.3 結果：Appealが「認められ」、WGアイテムではなくなった

ADの判断は、要約すると以下のとおりです。

現時点では「SLH-DSA TLS ドラフトを WG ドラフトとして進めるべきではない」
すなわち、WG採用は取り消し、個人Internet-Draftとして扱うのが適切

これにより、Appeal は「認められた」形となり、

SLH-DSA ドラフトは TLS WG の正式な WGアイテムではなくなった

というステータスが確定しました。

1.5 PQCなDraftをめぐる「ML-KEM と SLH-DSA の明暗」

上記をまとめると、今回の Complaint / Appeal の背景には、

ML-KEM
→ TLS側としても「これを中核PQC KEMとして使っていく姿勢」を強く示したい
SLH-DSA
→ NIST標準であっても、TLSのユースケース・コストを考えると「いま無理に入れるべきではない」

という TLS WG の現実的な判断があります。

IETF 124 TLS WG セッションでは、

ML-KEM：Complaint は退けられ、WGドラフトとして継続
SLH-DSA：Appeal が認められ、WGドラフトから外れる
ECDHE-ML-KEM：Meetecho Poll で 37/0/15 のコンセンサスを得て、Kyber 実験コードポイントの整理方針を確定

という形で、「PQCは何でもかんでも入れる」のではなく、性能・運用コストを踏まえて技術を選別するという WG のスタンスが、かなりはっきり打ち出された回だったと言えます。

2. 主要なワーキンググループドラフトの進捗

2.1 Extended Key Update (EKU)

ドラフト: draft-ietf-tls-extended-key-update-07 (2025-11-01更新)

概要

Extended Key Update は、TLSセッション中に暗号鍵を更新する際、より強力なセキュリティ保証を提供する機能です。鍵が侵害された場合でも、その影響範囲を限定できます。

セキュリティ目標：Post-Compromise Security

標準のキー更新は同じマテリアルから新しいキーを導出しますが、EKUはフレッシュなDiffie-Hellman鍵交換などを行うことで、Post-Compromise Security (PCS) を実現します。PCSとは、鍵が侵害された後でも新しい鍵交換により将来の通信の安全性を回復できる性質です。

この用語は「On Post-compromise Security」（2016年のIEEE論文）を参照しており、潜在的な侵害の影響範囲（影響範囲／ブラスト・レイディアス）を効果的に低減します。

主な技術的変更

メッセージ形式の統合
以前は3つの独立したコードポイントを登録していましたが、単一のExtendedKeyUpdateメッセージ（uint8サブタイプを持つ）に統合されました。サブタイプは key_update_request (0)、key_update_response (1)、new_key_update (2) の3種類で、将来の拡張に備えてIANAレジストリが設けられます。

エラー処理の簡素化
EKUがネゴシエートされた場合、必ず最終的に成功することが期待されるため、エラーコードは完全に削除されました。レスポンダーは多忙な場合に応答を遅延できますが、リクエスターは待ち疲れたら接続を終了できます。DTLSでは、リクエスターの再送信を防ぐためにレスポンダーがACKを送信します。

セキュリティ考慮事項の充実
セキュリティ考慮事項の初版が追加され、以下のような点が整理されました。

キー侵害のスコープ（どの鍵がどの範囲に影響するか）
DoS的な悪用の可能性と運用上のガイダンス
半二重のTLS実装が存在することへの注意喚起

セッション中には、

「アプリケーションキーのみが侵害され、長期鍵は侵害されていない」という前提の妥当性
EKUを行う前に最低バイト数（トラフィック量）のしきい値を設けるべきか

といった質問が出され、これらを反映する形でセキュリティ考慮事項をアップデートする方針が示されました。

今後の作業

TLS 1.3とのラベルおよびキー命名の整合（既に反映済み）
Exporter APIへの影響の明確化
- 実装によっては古いExporterを保持するための2つのAPIが必要になる可能性
実装者向けの情報提供として非規範的なステートダイアグラム（TLS/DTLS）のブラッシュアップ
さらなる実装レビューとセキュリティレビュー（FATT等）

PCSというキーワードはTLS WGでも前提知識として扱われている印象で、長期運用を意識した議論が多かったのが印象的でした。

2.2 PAKE

ドラフト: draft-ietf-tls-pake-00

概要

PAKE (Password Authenticated Key Exchange) は、パスワードを使用して安全に鍵交換を行う認証方式です。従来のパスワード認証とは異なり、パスワード自体をネットワークで送信せずに認証できます。ドラフトは IETF 123 以降に WG 採用されました。

複数ラウンドPAKEの統合は見送り

TLS 1.3ハンドシェイクに適合するPAKEは、共有シークレット導出のために2つのメッセージ（ClientHelloとServerHelloに1つずつ）を使用し、鍵確認はTLS Finishedメッセージで提供される必要があります。

3メッセージ（CPaceOQUAKE）や5メッセージ（CPaceOQUAKE+）を必要とするPAKEをサポートすると、RTT（ラウンドトリップタイム）が増加しハンドシェイクが複雑化します。WGは、TLSハンドシェイクへの侵襲的な変更は望ましくないという明確なコンセンサスを示し、複数ラウンドPAKEの統合は見送りとなりました。

代わりに、これらのプロトコル（Short Authentication Stringsを含む）は、チャネルバインディングを使用してTLSセッション確立後にカスタムのアプリケーションプロトコルとして実行することが推奨されます。

拡張機能形式の設計

PAKE拡張機能について、アルゴリズムごとに個別の拡張機能を使用する方式（プロトコル固有）と、単一の汎用拡張機能を使用する方式（現在の設計）が議論されました。WGは、複数のPAKEを同時に提供する場合の非論理的な状態を避けるため、PAKESchemeで識別する単一の汎用拡張機能を好む傾向を示しました。

クライアント列挙攻撃の防止

クライアントがPSK拡張とPAKE拡張の両方を提供した場合、サーバーはどちらかを選択する必要があります。サーバーがclient_identityの認識有無に基づいて選択すると、攻撃者にクライアント列挙攻撃の機会を与える可能性があります。

この問題への対策として、サーバーは認証メカニズムに対する自身のプリファレンスに基づいてPSK/PAKEを選択すべきであるというテキストの追加が提案されました。

今後の進展

オープンイシューの多くは数行レベルの修正で、順次ドラフトに反映される予定
純粋なPQC PAKEであるOQUAKE（2メッセージに収まる）を登録する意向が示されました
「パスワードしかないユースケースでは、PAKEは有力な選択肢になる」といった運用上のメッセージをドラフトに明記すべき、というコメントも出ています
一方で、
- PAKEは試行回数制限が前提
- 双方が生パスワードを保持しなければならない
  といった注意点も強調されており、セキュリティモデルの説明を厚くしていく方向性が確認されました

2.3 Large Record Sizes

ドラフト: draft-ietf-tls-super-jumbo-record-limit-02 (2025-11-03更新)
ステータス: オープンイシュー解決済み、WGLC実施提案

概要

現在のTLSレコードサイズ制限（16KB）を超える大きなレコードをサポートする拡張です。

背景: 現代のネットワーク環境では、高速回線や大容量データ転送が一般的になっており、16KBの制限がオーバーヘッドとなる場合があります。本拡張により、より効率的なデータ転送が可能になります。

更新内容

前回のIETFで受けたコメントに対応し、可変長フィールドをMLS（RFC 9420, Section 2.1.2）で定義されているvaruint（QUICに似た最小サイズエンコーディングを要求する可変長整数形式）に変更しました。拡張値がRFC 8449と同一であることも明確化されています。

セッションでは、「Open Issueはすべて解決済み」「実装も進行中であり、WGLCをかけた上で実装待ちとするのがよい」という意見が出されました。

2.4 ML-KEM only

ドラフト: draft-ietf-tls-mlkem-05 (2025-11-02更新)

概要

TLS 1.3向けの純粋なPQCなCiphersuite（セッション中の鍵交換をML-KEMのみで提供するDraftです。従来の楕円曲線暗号とのハイブリッドではなく、ML-KEMのみを使用します。

重要性: ハイブリッド方式（楕円曲線 + ML-KEM）は移行期の選択肢ですが、純粋なPQC方式は、楕円曲線暗号に脆弱性が発見された場合でも安全性を保てる最終的な目標です。

対応アルゴリズム:

MLKEM512
MLKEM768
MLKEM1024

推奨ステータスに関する議論

推奨ステータスを「N」（通常）から「D」（非推奨）に変更する提案がありましたが、WGはこれを拒否しました。理由は2つあります。

変更には標準化アクションが必要となること
ML-KEMがIANAレジストリ上でRC4、NULL暗号、DES、MD5といった古く壊れた暗号と同じグループに分類されてしまい、技術的に不適切で誤解を招く可能性があること

本ドラフトは BoringSSL、OpenSSL、AWS s2n、Rustlsなどで既に実装されており、セッションでは

「Recommended を D にする PR はクローズし、WGLCに進む」

という方向性で合意が形成されました。
前述の Complaint が退けられたことと合わせて、TLS WG として ML-KEM を中核PQC KEM として前に進める姿勢が明確になっています。

2.5 Well-known URL for ECH

ドラフト: draft-ietf-tls-wkech-11 (2025-11-03更新)
ステータス: GitHubリポジトリ移管後、WGLC予定

概要

ECH（Encrypted Client Hello）のサービスパラメータを公開するためのWell-known URLに関するドラフトです。

ECHとは: TLSハンドシェイクの最初のメッセージ（ClientHello）を暗号化し、接続先サーバーの情報を第三者から隠蔽する技術です。

目的と仕組み

Zone Factory（DNSオペレーター）がクライアント対面サーバー（CFS）の情報をポーリングし、DNSに公開できるようにすることが目的です。公開される情報には、ECHキー、ALPN値、その他のサービスパラメータが含まれます。例えば、https://defo.ie/.well-known/origin-svcbのような形式で提供されます。

IETF 124セッションでは、

GitHubリポジトリを tlswg org に移管したこと
既存のオープンイシュー／コメントはすべて解決済みであること

が報告され、「リポジトリ移行を反映した新バージョンを出した上でWGLCに入る」という方針が確認されました。

3. Designated Expert (DE) レポートとレジストリ更新

Rich Salz氏より、IANAレジストリの更新に関する報告がありました。

Designated Expert (DE) とは: IETFプロトコルのパラメータや拡張機能の登録申請を審査し、IANAレジストリへの登録を承認する専門家です。TLS WGでは、新しい暗号スイート、拡張機能、アラートタイプなどの登録を管理しています。

セッションでは「DEレポートはスライドを参照」となり、会場からの質問や追加議論は特にありませんでした。以下はスライド内容を踏まえて整理した要点です。

3.1 文書参照の更新

TLS 1.2 frozen、RFC8446bis、RFC8447bisなど、多くの文書参照が最新のドラフトへと更新されました。

3.2 新しいレジストリとフィールド

新しいRRC（Return Routability Check）メッセージタイプ
SSLKEYLOGFILE ラベル（TLSセッション鍵をログファイルに記録するための標準形式）
ECHConfig 関連の拡張

が追加されました。RRCは、DTLS 1.2/1.3でConnection IDを用いる際に、経路の健全性を検証するためのサブプロトコルです。

3.3 追加された暗号アルゴリズム

アラートと署名スキーム

新しいアラートタイプとして general_error が追加
署名スキームには ML-DSA（PQCデジタル署名）が3種類追加：MLDSA44、MLDSA65、MLDSA87

サポートグループ

ハイブリッド鍵交換用の SecP384r1MLKEM1024 が追加

NIST軽量暗号

TLS_ASCONAEAD128_ASCONHASH256 など、NIST軽量暗号プロジェクトに基づく新しい暗号スイートが登録されました。
これは、外部のNIST仕様のみを根拠に TLS レジストリエントリが作成された初のケースとしても位置づけられます。

3.4 SLH-DSAに関するCiphersuite

未採用となった SLH-DSA に関するDraftから派生した 12 個の暗号スイートが登録されることになりました。指定エキスパートは、未採用ドラフトを起点とする多数の登録に懸念を示しつつも、レジストリの運用ポリシーに従って登録を進めています。

4. Non-WG item： PEM file format for ECH

ドラフト: draft-farrell-tls-pemesni-09

Stephen Farrell氏より報告がありました。

概要

PEM (Privacy Enhanced Mail) ファイル形式を使用して ECH (Encrypted Client Hello) の設定を行うための仕様です。TLSサーバーでの設定ファイルを容易にし、運用ツールとの連携をシンプルにします。

ファイル構成

以下の要素で構成されます：

ゼロまたは1つの PKCS#8 エンコードされた秘密鍵
1つの base64 エンコードされた ECHConfigList

実装状況

以下の実装でサポートされています：

OpenSSL の ECH 機能ブランチ
lighttpd
freenginx
apache2 httpd

進め方

Area Director（Paul W.）が、RFC 7468 と同様に、ADスポンサーシップルートでのプロセスを試みることに合意しました。TLS WG としては、ECH の実装者が扱いやすい設定フォーマットを提供することで、ECHの普及を後押しする狙いがあります。

5. まとめと今後の予定

セッションの総括

IETF 124 TLS WGセッション1では、TLSプロトコルのPQC対応と、長期的なセキュリティ強化に向けた重要な決定が行われました。特に、

ML-KEM と SLH-DSA をめぐる Complaint / Appeal の決着
ECDHE-ML-KEM に関する Meetecho Poll（37/0/15）によるコンセンサス確認
実験的なPQCコードポイント（Kyber実験値）の整理方針の確定

は、今後数年にわたる TLS のPQC移行戦略に大きな影響を与えるトピックです。

セッションでの主要な成果

ECDH(E)-ML-KEMの標準化推進
実験的コードポイントの廃止に向けて、ドラフト全体を Standards Track に移行し、Meetecho Poll（Yes 37 / No 0 / No Opinion 15）で得られたコンセンサスに基づき 1 週間のWGLCを行う方針が決定。
→ 将来の商用TLSスタックにおけるPQC移行の「基準線」となる文書として位置づけられます。
Extended Key Updateの成熟
メッセージ形式の統合とエラー処理の簡素化、セキュリティ考慮事項の具体化。
→ 長期間張り付き運用されるTLSセッションでも、PCSを意識した安全な鍵更新が現実的な選択肢になりつつあります。
PAKEの方向性明確化
複数ラウンドPAKEの統合見送りと、アプリケーション層での実装推奨。
→ TLSハンドシェイク自体はシンプルさを維持しつつ、アプリケーション側で柔軟にPAKEを活用する方針が確認されました。
ML-KEM onlyの実装進展と位置づけ確立
主要TLSライブラリでの実装完了と、Recommended値をDに下げる提案の却下。
→ ハイブリッドだけでなく「純PQCスイート」をどのタイミングで有効化するか、運用側の判断材料が増えています。
レジストリの充実
PQC関連のアルゴリズムやNIST軽量暗号の登録、RRCやSSLKEYLOGFILEラベルの整備。
→ 実装者がIANAレジストリを見れば、PQC/軽量暗号を含む最新の選択肢が一望できる状態に近づいています。
SLH-DSAに対するAppealの決着
Appealが認められ、SLH-DSA TLS ドラフトは WG アイテムではなくなることが確定。
→ NIST標準だからといって自動的にTLSに入るわけではなく、実運用コストを踏まえた取捨選択が行われていることが明確になりました。

今後の予定

チェアは、本セッション後に以下のような形で WG LastCall（WGLC） を進める予定であることを確認しました：

draft-ietf-tls-wkech
→ リポジトリ移行などの小修正を反映した新版を出した後、WGLC。
draft-ietf-tls-super-jumbo-record-limit
→ 既存のオープンイシューをクローズ済みとし、実装状況を見ながらWGLC。
draft-ietf-tls-hybrid-design (ECDH(E)-ML-KEM)
→ Standards Track に移行したうえで、Kyber実験コードポイントをDマークする内容を含めて1週間のWGLC。

セッション2は水曜日に予定されており、残りのドラフトおよび追加のテクニカルディスカッションが行われる予定です！というか今参加していますwww

参考リンク

セッション情報

最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ: https://gmo-connect.jp/contactus/

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up