みんな、TLSは好きですか？
GMOコネクトの菅野 哲（かんの さとる）でございます。
みんな、IETF124 を満喫しているでしょうか？
この記事では、前回まとめた セッション1 に続いて、11月5日（水）に行われた TLS WG セッション2（正式名称じゃないですが便宜上そう呼びますw）の内容をお届けします。
まだ、IETF124 TLS WGセッション1へのリンク を読んでいないという方は、次の記事を参照いただけると嬉しいです✨
はじめに
-
開催日: 2025年11月5日（水）
-
場所: カナダ・モントリオール（IETF 124 会場）
-
対象 WG: TLS (Transport Layer Security) WG
-
セッション情報: IETF Datatracker
-
アジェンダ: agenda-124-tls
-
議事録: minutes-124-tls
-
本記事のフォーカス:
- DTLS 1.3（rfc9147bis）のクリーンアップ
- ECH（Encrypted Client Hello）の実運用を支える仕組み
- TLS を使った Service Affinity 提案と、そのレイヤリング議論
セッション1が「PQCドラフトの明暗（ML-KEM / SLH-DSA / 実験コードポイント整理）」だったとすると、
今回のセッション2は、実装・運用に近い「プロトコルの手触り」を詰めていく回という印象でした。
1. ワーキンググループドラフト
1.1 DTLS 1.3（draft-ietf-tls-rfc9147bis）
📄 発表資料: スライド | Internet-Draft
久しぶりにリアルで目視したEric Rescorla 氏（ekr）から、RFC 9147 のクリーンアップ版である rfc9147bis の状況が報告されました。
-01 版では、主に既知のエラータ対応など、コンセンサス済みのバグ修正が中心です。
概要
-
対象: DTLS 1.3（RFC 9147）の改訂版
-
内容:
- エラータの反映
- 実装経験にもとづく細かい仕様の調整
-
ねらい:
- 「挙動があいまいなところ」を埋めておき、実装間の相互運用性を高めること
その中でも特に議論が盛り上がったのが、次の3点です。
1.1.1 リプレイ検出（Replay Detection）を必須化すべきか
現行の RFC 9147 では、リプレイ検出はオプション扱いとなっています。John Mattsson 氏は、特にハンドシェイク後の認証において、リプレイ検出を必須にすべきと提案しました。
しかし、この提案に対しては慎重論も根強く出ました。Paul Wouters 氏は IPsec WG の議論を引き合いに出し、パフォーマンス上の理由からリプレイ検出を無効化する選択肢が検討されていることを紹介しました。特に DTLS-over-SCTP のように、トランスポート層自体がリプレイ検出機能を持つ場合、DTLS 側で二重にリプレイ検出を行うことは無駄であり、パケットドロップのリスクも増えてしまいます。
こうした議論を経て、会場では折衷案が支持される流れになりました。それは「アンチリプレイ機能を提供しないトランスポート上で動作する場合には、DTLS 側でリプレイ検出を行わなければならない」という、条件付き必須化のアプローチです。これにより、セキュリティ要件と実装の柔軟性のバランスが取れた形に落ち着きそうです。
1.1.2 Epoch 0 における ACK（Acks in epoch 0）
Epoch 0 での ACK の扱いは、実装者にとって特に悩ましい問題です。RFC 9147 では Epoch 0 での ACK が定義されているものの、この ACK を DTLS 1.2 クライアントに送信すると、未知の ContentType として扱われ、実装によっては予期しない動作を引き起こす可能性があります。
Martin Thomson 氏は、この互換性リスクを強く懸念していました。DTLS 1.2 実装が見知らぬ ACK メッセージをきれいに無視してくれる保証はなく、実装依存で事故が起きるリスクがあるため、「とりあえず送ってみて様子を見る」という設計は避けるべきだと主張しました。
一方で、MT 氏自身も認めていたのは、「実装が仕様通りに未知のデータを破棄してくれるなら、DTLS 1.3 スタックは常に ACK を送信し、相手側がサポートしていないものは無視してもらう」というアプローチの理論的可能性です。しかし David Benjamin 氏が「自分たちのスタックが予期しない ACK を正しく扱えるか確認が必要」とコメントしたように、実装の現実はそう単純ではありません。
結果として、David Benjamin 氏の提案する 「Epoch 0 で ACK を送ること自体を禁止する」 という方向が有力視されています。ハンドシェイク完了には ACK は必須ではないため、この制約による実害は限定的です。ただし、Classic McEliece のような大きな鍵を含む ClientHello の場合、再送が増えて非効率になる可能性は残ります。
Paul Wouters 氏は IKEv2 の類似メカニズムにおいて、ガベージの破棄と欠落パケットの再送信によって、一部の接続がハンドシェイクを完了できないケースがあることも紹介しており、この問題の複雑さを物語っていました。
1.1.3 平文シーケンス番号（Plaintext Sequence Numbers）
NVIDIA から、暗号化されていないシーケンス番号を許可する拡張の提案がありましたが、この点については比較的すんなりと不採用の方向で合意されました。
Deirdre 氏は SSH における類似のバグを例に挙げ、「シーケンス番号は暗号化しておくのが安全で、敢えて平文に戻す理由は薄い」という見解を示しました。会場からも明確な反対意見は出ず、DTLS コア仕様には取り込まないという結論になりました。
Turner 氏が ekr 氏に対して DTLS 1.3 / 1.2 のエラータ確認を依頼する Issue を作成することになり、この議題は締めくくられました。
1.2 小まとめ：DTLS 1.3 議論のポイント
今回の rfc9147bis 議論を一言でまとめると、「実装現場でぶつかっている微妙なところを、標準側できちんと言語化しよう」 という動きでした。
リプレイ検出の必須化条件、Epoch 0 での ACK の扱い、平文シーケンス番号の不採用——いずれも、セキュリティと実装負荷、既存実装との互換性のバランスを取る、かなり「現場寄りの調整」になっている印象です。特に DTLS 1.2 との互換性を意識した慎重な議論は、標準化プロセスの成熟度を感じさせるものでした。
2. Non-WG Draft 関連
ここからは、TLS WG で議論された Individual Draft（Non-WG Draft） を3本についてまとめます。
2.1 ECH 用 PEM ファイル形式（draft-farrell-tls-pemesni）
📄 発表資料: スライド | Internet-Draft
Stephen Farrell 氏から、TLS サーバ設定を簡素化するための ECH（Encrypted Client Hello）専用 PEM ファイル形式 が紹介されました。
概要と設計思想
ECH の設定管理を「1ファイルにまとめて」扱えるようにするのが狙いです。フォーマットは以下のようにシンプルな構造になっています。
- PKCS#8 エンコードされた秘密鍵（0 または 1 個）
- その後に Base64 エンコードされた
ECHConfigListが 1 つ続く構造 - 秘密鍵なし（0 個）で、ECH 設定だけを持つファイルも作成可能
実装状況
すでに実装が相当進んでいるのが印象的でした。OpenSSL の ECH ブランチで生成・消費に対応しており、サーバ実装側でも lighttpd、freenginx（2025-09-23 リリース 1.29.2 の一部）、Apache httpd（アップストリーム済み・未リリース）、HAProxy（マージ予定）、nginx（PR 議論中）といった具合に、現実に使われそうな顔ぶれが揃いつつある状態です。
議論の焦点
Yaroslav 氏から「複数の ECH Config を持てるか？」という確認があり、Farrell 氏は異なる暗号鍵を持った複数の ECH Config を含めることは可能だが、対応する秘密鍵は 1 つという整理を説明しました。MT 氏は、複数の鍵が必要な場合は複数のファイルを使えばよく、ECH Config の結合は比較的単純だと補足しました。
ekr 氏から「秘密鍵なしで ECH Config だけを含むファイルも作れるのか」という確認もありましたが、これも「可能」との回答でした。
興味深かったのは Usama 氏の質問です。「以前 ECH には extensive な形式的解析が行われたが、この変更で再度形式的解析が必要か？」という問いに対して、Deirdre 氏が「これはプロトコルではなくファイル形式の話なので、TLS や ECH の鍵スケジュール、暗号設計には影響しない。形式的解析は不要」と明快に答えていました。
Paul Wouters 氏は RFC 7468（PEM フォーマット系の RFC）の前例を踏まえ、AD スポンサー付きでの標準化ルートを進めることに同意を示しました。ECH デプロイの「運転免許証ケース」を整える話、という感じで、割とサクサク進んでいた印象です。
2.2 認証された ECH 設定の配布と更新（draft-sullivan-tls-signed-ech-updates）
📄 発表資料: スライド | Internet-Draft
Nick Sullivan 氏から、ECH 設定の配布・ローテーションを認証付きで行うメカニズムが提案されました。
背景となる課題
ECH クライアントは、最新の ECHConfig を DNS HTTPS/SVCB レコードや well-known HTTPS エンドポイントといった帯域外チャネルで取得します。ここで問題になるのは、古い設定が原因で ECH が失敗した場合の対処です。
サーバは新しい設定を返すことができますが、public_name の証明書が有効でないと、クライアントはその更新を信頼してよいか判断できません。その結果、運用上の柔軟性やプライバシー戦略の自由度が制限されてしまいます。
提案内容：2つの認証モード
ドラフトでは、ECHConfig に署名情報を持たせるための拡張を導入します。クライアントが「これは正当な権限者によって発行された ECH 設定だ」と確認できるようにするのが狙いです。
1. Raw Public Key (RPK) モード
初期設定で、署名に使える鍵の SPKI ハッシュ（SHA-256）をリスト化しておき、サーバはそのうち 1 つの鍵で更新に署名します。このアプローチのメリットは、多数の public_name に対して証明書を用意しなくてもよく、プライバシー保護やカバードメイン設計の自由度が高まることです。
2. PKIX（証明書ベース）モード
通常の証明書チェーン（信頼されたルート）を使い、SAN が public_name をカバーし、クリティカルな ECH-config-signing 拡張を持つ証明書で署名します。
議論：実用性と信頼モデルへの懸念
Stephen Farrell 氏はこの取り組みを支持する姿勢を示しましたが、MT 氏は根本的な疑問を投げかけました。「public_name 経由での間接的な認証方式に、どこまで価値があるのか」という点です。Nick Sullivan 氏は、サーバが public_name を選択するのであって、外側の SNI とは異なると説明し、現状のシステムの制約上、この方式が必要だと主張しました。
David Adrian 氏からは、より本質的な問いが出されました。「Google のような大規模プレイヤーの実運用課題をどこまで解決し、本当に ECH 採用を押し上げるのか？」Nick Sullivan 氏は Cloudflare として実際に展開する意向があると表明しましたが、David Adrian 氏は「Google が抱えているデプロイの課題は、この更新メカニズムでは解決しない」と指摘しました。
PKIX モードについて、ekr 氏が CA と議論しているかを確認したところ、まだ行っていないとのことでした。ekr 氏と Alessandro Ghedini 氏はともに、どちらか一方を選ぶなら RPK モードを好むとコメントしていました。
Dennis Jackson 氏は、マルチ CDN デプロイメントにおける ECH は非自明な問題であることを指摘しつつ、このドラフトが既存の ECH の動作を根本的に変えるものではないことを確認していました。Christian Huitema 氏も、マルチ CDN デプロイメントにおける初期信頼の確立方法について苦慮していることを述べていました。
個人的な感触としては、「ECH を"ちゃんと回す"ための実務仕様が、徐々に埋まってきた」という印象です。セッション1で見た「PQC の核」とは違う意味で、ECH の地盤固めが進んでいるように感じました。
2.3 TLS に基づく Service Affinity ソリューション
Service Affinity Solution based on TLS（Aijun Wang 氏）
📄 発表資料: スライド
最後はボーナスプレゼン枠として、Anycast 環境における Service Affinity を TLS で実現しようという提案です。
モチベーション
Anycast サービスでは、ネットワーク状況に応じて「今一番良いサーバ」を選びたい一方で、一度接続したクライアントは、できるだけ同じサーバに張り付けたいという要求があります。従来は、ネットワーク機器側で「顧客ごとの状態テーブル」を持つことで対応していましたが、スケーラビリティや柔軟性で限界が見えつつあります。
提案メカニズム概要
提案では、TLS を使って Service Affinity を実現することで、「ネットワーク機器側ではステートレスに近づけつつ、クライアントは同じサーバに戻れるようにしよう」という狙いがあります。
大まかな流れは以下の通りです。
- クライアント A が、サービスの Anycast IP に向けて
migration_support拡張を含む最初のClientHelloを送信 - ルータがリアルタイムのネットワーク状態を見て、最適なサーバ（例: IP4）を選択
- サーバが通常どおり TLS 1.3 ハンドシェイクを完了
- サーバが
NewSessionTicketでMigrationTokenを送信（ターゲットアドレス、セッション ID、有効期限、ノンス、署名などを含む） - クライアントは、この
MigrationTokenを用いて、特定サーバ宛に接続を再確立
このために、migration_support 拡張、migration_token、migrate_notify アラートなどの新しい要素が定義されています。
レイヤリングの根本的な問題：ekr / MT からの批判
この提案に対しては、かなり本質的な批判が出ていました。
ekr 氏の指摘：TLS は間違ったレイヤー
ekr 氏は、これは TLS 層の問題ではなく、アプリケーション層で処理すべきだと主張しました。TLS 層でアドレスマイグレーションを行うと、アプリケーションは「どのパケットが届いて、どれが失われたか」を把握できないまま、ネットワーク障害が非同期に発生し、結果としてアプリケーション状態が壊れる可能性があります。
Aijun Wang 氏は「TLS 層で実装すれば、多くのアプリケーションに適用できる」と反論しましたが、ekr 氏は「それは正しいが、それでもやはり壊れている」と応じました。Wang 氏が「QUIC にも類似のメカニズムがある」と指摘すると、ekr 氏は重要な違いを指摘しました。QUIC は接続状態を維持したままアドレスを切り替えるのに対し、この提案は毎回新しい TCP コネクションを張り直すため、本質的に異なるというのです。
MT 氏の指摘：接続継続性の欠如
MT 氏も同様の懸念を表明しました。見た目は QUIC の優先アドレスメカニズムに似ているが、QUIC が提供する「接続継続性」の特性を欠いていると指摘しました。TCP ベースで新しいコネクションを貼り直すと、アプリケーションからは普通に「接続断」と見えるだけです。
結局、別途「セッション継続レイヤー」が必要になり、「TLS 層だけで完結するきれいな解決策」にはなっていないのでは、という指摘でした。MT 氏は、この種の要件には HTTP リダイレクトを使って Anycast から直接 IP アドレスへの切り替えを行う方が適切だと示唆していました。
Wang 氏は、これらのコメントをメーリングリストに送ってほしい、Palo Alto のチームに助けてもらいたいと述べて、セッションは締めくくられました。
3. まとめと所感
セッション1が 「PQC ドラフトの選別とコードポイント整理」 だったのに対して、今回のセッション2は、より運用・実装寄りの「現場の課題」を形にしていく回だったと感じました。
本記事で取り上げたポイントをざっくり振り返ると：
DTLS 1.3（rfc9147bis）
実装者が悩んでいたグレーゾーンを標準として明文化していく作業が着実に進んでいます。リプレイ検出の条件付き必須化、Epoch 0 の ACK 問題、平文シーケンス番号の不採用——どれも、セキュリティと実装負荷、既存実装との互換性のバランスを取る現場寄りの調整です。特に DTLS 1.2 との互換性を慎重に検討する姿勢は、標準化プロセスの成熟を感じさせます。
ECH 関連（PEM 形式 / Signed ECH Updates）
ECH を「本番で回していく」ための地ならしが着々と進んでいます。PEM フォーマットで設定ファイルとしての扱いやすさを整備し、署名付き ECH 更新でキーローテーションと設定配布の信頼性を強化する——実装が先行している PEM 形式と、信頼モデルについて慎重な議論が続く Signed Updates という対照的な状況が印象的でした。
Service Affinity in TLS
Anycast 環境で顧客を同じサーバに寄せ続けたい、という現場ニーズを TLS に押し込もうとする試みでしたが、レイヤリングや接続継続性の観点から、かなり厳しい突っ込みが入りました。ekr 氏と MT 氏の批判は、「どのレイヤーでやるべきか」という根本的な問いを突きつけるものでした。
TLS WG 全体としては、「なんでも TLS に押し込む」のではなく、プロトコルの責務分離と、実装現場のリアリティを両方見ながら、やるべきことを選別していくという姿勢が、セッション1・2を通じてかなりはっきり見えてきたように思います。
PQC / ECH / DTLS / Service Affinity と、トピックは多岐にわたりますが、どれも 「インターネットの実際の運用をどう安全にしていくか」 という一本の線でつながっているのが、TLS WG らしいところだなと感じました。
セッション1の記事とあわせて読んでもらえると、IETF124 における TLS WG の「全体像」を把握しやすくなると思います。ぜひ、合わせて読んでいただけると嬉しいです。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。