TLS WG @ IETF 126 議事要約

木曜 2026-07-23 07:00–09:00 UTC（session 35590、2時間）／金曜 2026-07-24（session 35591、90分）

Notes: Rich Salz, Muhammad Usama Sardar（木）／Mike Ounsworth, Usama Sardar, Morgane Guerreau（金）
情報源: スライド13点、session notes、録画文字起こし2本、投票ログ2本、agenda
議題から拒否された項目: draft-usama-tls-fatt-extension

1. Chairs からの WG アップデート（木）

苦情・アピール

ML-KEM／ML-DSA 関連で DJB から chairs 宛に 6/27 付の苦情2件（"jeopardy claim"、"charter complaint"）。いずれも却下。他のアピールは IESG・IAB・ISOC Board 側で処理中で、WG では扱わない方針。

文書ステータス

• ecdhe-mlkem: Standards Track、X25519MLKEM768 を Recommended=Y に変更する rough consensus を chairs が判断、IETF Last Call を通過済み。
• mlkem: Informational、全値 Recommended=N で進める rough consensus を判断（これがアピール対象）。
• extended-key-update: authors は WGLC 準備完了と考えており未解決 issue／PR もないが、FATT の初期 sniff test で「解析が必要」と出たため、WGLC を始めても EKR から即座に形式解析を要求されるだけと判断して待機中。
• super-jumbo-record-limit: Hannes が2実装、John Mattsson が同僚に3つ目の実装を打診中。

相互依存の指摘（EKR）

supplemental certificates を採用するなら、extended key update と合同で形式解析すべき。EKU を単独で標準化した後に supplemental certificates と噛み合わないと判明しても、もう変更できない。Hannes からは Nick が既存 post-handshake authentication を含めて EKU の形式解析を進行中との報告。

Jonathan Hoyland は6〜7年前に書いた合成可能な鍵スケジュール拡張の draft（draft-jhoyla-tls-extended-key-schedule）を挙げ、他提案と解析上 composable にする指針を authors に出す価値があるかを提起。

Thom Wiggers（FATT メンバー、個人として）は「拡張可能プロトコルでは 本体 / 本体+A / 本体+B を検証しても A+B については何も言えない。全組合せの検証は現実的でないので、併用が想定される拡張については authors が Security Considerations で相互作用を明示すべき」と整理。

メーリングリストの荒れ

Chairs（Sean Turner）は「本当にひどい状態」と率直に述べ、月次リマインダが機能していないこと、chairs の moderation が遅かったことを認めた上で、スレッドの squelch を今後積極的に行うと表明。IETF 全体の moderator team も稼働開始しており、TLS が優先対象になる見込み。

• EKR: chairs は draft を処理するだけでなく戦術的判断を下す立場にあり、話題の順序付けや「今は off-topic、後で on-topic」といった舵取りにもっと権限を感じてよい。
• Paul Wouters: 「透明性のため TLS リストに CC します」型のメールも止めるべき。メタレイヤが増えるだけ。
• Christian Huitema / Daniel Migault: 異議の抑圧にはならないよう配慮を。例外的状況で作られた規則が後で自分たちを縛る懸念。
• Lars Eggert: 平常時の moderation は問題なかったが、ここ数週間〜数か月はリストが「TLS を前進させる場として意図的に破壊されている」例外状況であり、強い措置を取ってよい。
• Tanja Lange: 逆に「議論するな」と言われた結果、editor からの応答がなく一方通行になっている問題もある。変更内容が未議論なら議論を許可・要求すべき。

Sean は「何人もが『この仕事を持ち込みたいがリストが有害すぎる』と個人的に伝えてきている」と述べ、実装者が離れれば WG の意味がないと危機感を示した。off-topic の定義（RFC 3683 ベース）に「過度なプロセス議論」を追加予定。

FATT

「でこぼこ道だった」と認めつつ、GitHub ページで誰が担当し何が送られたかを公開して透明性を確保。collaboration に関する PR#24 をレビュー依頼。FATT を続ける理由として、TLS 1.3 のとき研究者と協調しなかったせいで公開直前にロゴ付きの攻撃発表が繰り返された経緯を挙げた。

※ session notes 側には 80/0/3、49/2/8 とありますが、上表は polls ログの値です。

• Viktor Dukhovni: 解析しやすくするために実装しにくくなる「尻尾が犬を振る」状態を懸念。TLS 1.3 の PSK は統合しすぎて実装が非常に複雑になった例。実装・使い勝手を先に設計し、解析は後にすべき。
• Usama Sardar: 透明性の問題は改善されたが、既に形式解析に着手している人がいる場合、その判断（＝解析が必要という見立て）を chairs は考慮すべき。chairs が単独で「解析不要」と決めて WG に理由も示さないのは不公平。
• Thom Wiggers: FATT は形式解析をするのではなく、文書の主張が文書内の議論で裏付けられているかを評価する。extended-key-update なら「post-compromise security を主張しているが edge case は？」という判断で、その先は authors と WG が決める。
• Felix Linker: FATT は形式解析の専門家のためではなく、詳しくない人が informed opinion を得るためのツール。必須でなくとも解析には価値がある。
• EKR / Chris Wood: 形式解析も一種のレビューであり特別なルールは不要。特別ルールが要るなら既にどこかで脱線している。
• Mike Ounsworth（No 投票の理由）: authors は文書上で定義された集合だが「形式解析を行う人」は不定。IETF に参加する解析者を、参加していない優れた研究者より優遇する形になるのは反対。

Sean の回答: chairs が真空中で決めているわけではなく、文書受領時に「他に誰と話しているか」等を確認している。今後は送る／送らないの判断とその理由を必ずメールで通知するプロセスにする。

2. DTLS 1.3 — draft-ietf-tls-rfc9147bis（EKR）

Hannes が issue を大量に PR 化し、EKR が取り込んだ結果、提起済み issue のほぼ全てに対応済み。

-01 からの変更: post-handshake の KeyUpdate 明確化 [EID 8047]／ACK 内の未来 epoch チェックを必須化 [EID 8108]／epoch 2^48 には message sequence number の制約で到達不可（実質 2^16）[EID 8050]／バージョンネゴ前の ACK 処理の明確化／不正レコード処理テキストの整理（drop を推奨）。

PR#317 replay protection の必須化

Montreal での懸念は、SCTP（Michael Tuexen）が OBE、性能（Paul Wouters）は根拠が弱いと判断。

• David Benjamin: 支持。ただし post-handshake は sequence number があるので特に重要な理由が分からない（EKR も撤回可と応答）。
• Martin Thomson: QUIC の性能プロファイルに replay protection が現れたことは一度もない。実装は極めて安価。必須にすべき。
• Hannes: IPsec のデータセンター通信では sequence number のコストが実測される（Google も一部で無効化）。ただし今回のケースは SCTP の件が消えた分だけ弱い。ハッカソン後に性能解析を行い最終回答する予定だが反対はしない。post-handshake メッセージが application traffic secret を使うため「replay protection がオプション」と読めてしまう表現の混乱もあった。

反対者なしでマージ。

PR#326 epoch closure: David Benjamin のレビュー由来。いつ閉じてよいか／いつ閉じなければならないかを詳述。EKR は基本的に問題ないと見るがレビューを募集（David Benjamin, Martin Thomson, Ana Wein を名指し、1か月程度で）。

Issue #291 ACK の epoch 遷移中の扱い: 最後の残課題。全体を通して漏れがないか確認する。

これらが片付き次第 WGLC を要請予定。「pre-last-call」として今のうちに issue を出すよう呼びかけ。

Hannes からは相互運用マトリクスの作成（OpenSSL 実装が進行中、mbedTLS ほか）と、学生による DTLS 1.3 の形式解析（extended key update で使った Promela/SPIN ベースの手法を base handshake に適用、同期の corner case を確認）の報告。実装リストは Chris Wood の tlsworkinggroup.org へ PR を出す方向。

3. Authenticated ECH Config Distribution and Rotation — draft-sullivan-tls-signed-ech-updates-02（Alessandro Ghedini）

問題: RFC 9849 では retry path が public_name の証明書に結び付いており、(a) 全 public name に CA 証明書が必要、(b) ECH を終端する全エンドポイントが public name の秘密鍵を共有、(c) public name が少ないほど鍵漏洩・名前ブロック時の blast radius が大きい。

提案: DNS の ECHConfig に ech_authinfo 拡張で許可された署名鍵のハッシュを掲載。ECH 拒否時のリトライ config に ech_auth（SPKI・署名・not_after）を付し、クライアントは TLS 証明書ではなく署名とタイムスタンプを検証する。結果として public name ごとの CA 証明書が不要になり、クライアントごとに異なる public name も可能、署名はオフラインで行えるため TLS サーバに署名鍵を置かなくてよい。

-02 の変更: PKIX 方式を削除し RPK 専用に単純化（CA との調整が不要）／ech_auth に明示的な boolean disable フィールドを追加（zero-length ECHConfigList 慣習を置換）／両拡張を high-order bit 付きの mandatory extension codepoint に変更し、旧クライアントが壊れずに config をスキップするように／1つの ECHConfig が両拡張を持つことを禁止。

実装: Rust/Go/C の interop harness、BoringSSL ベースと NSS ベースが WIP（未 interop）。

議論

• EKR（前夜にメール済）: replay には2種類ある。鍵入り config の replay は鍵が漏れていない限り比較的軽微だが、disable 付き config の replay は深刻で、有効期間中 ECH を丸ごと無効化できてしまう。設計判断として正しい可能性はあるが、帰結を明示すべき。そもそも署名付き disable config を許すべきか自体が論点。採択するなら open issue として残すべき。
• Dennis Jackson: 接続にバインドする設計も可能だが、その場合は署名鍵を TLS サーバ上に置く必要が生じる。トレードオフ。
• Alicja Kario: クロックドリフト。経験上、TLS クライアントの 1% 以上は実時刻から1時間以上ずれている。有効期間 24 時間だと相当数に影響するので、「24 時間前の鍵でも動く」必要があることを draft に明記すべき。鍵のオーバーラップも含めて。

貢献者が十分いそうなのでリストで採択確認へ。

4. Workload Identifier Scope Hint — draft-rosomakho-tls-wimse-cert-hint-02（Yaroslav Rosomakho）

mTLS は bot・workload・一部プロキシ・OT/IoT には有効だが、ブラウザには向かない。現状、公開 API で mTLS を選択肢として提供するには SNI ベースで別エンドポイントを立てる必要がある（CertificateRequest を送ると想定しないクライアントが予期しない挙動を取るため）。

提案: ClientHello 拡張に workload identifier scope（WIMSE workload identifier の scheme + authority/trust domain 部分、例 spiffe://… の先頭2要素）のリストを載せる。拡張の存在自体が「CertificateRequest を受けても壊れない」「列挙した scope の証明書を出せる」ことを示すヒント。サーバの挙動は実装依存（CertificateRequest を出す／出さない／接続を落とす）。

scope を含める理由: マルチテナント／フェデレーション環境ではクライアントが複数の workload identifier を持ちうるが TLS では1つしか出せない。サーバ側も数千顧客の trust domain を CertificateRequest に全列挙するのは不可能かつ顧客リストの開示になる。

プライバシー: 空リストが有効（実質「mTLS 要求フラグ」）。ECH と組み合わせ、outer ClientHello は空リスト、inner に実際の scope を入れるパターンが可能。

議論

• Viktor Dukhovni: DANCE WG に完成間近のほぼ同一機構の文書がある（クライアントが DANE TLSA を公開するドメインを示し、クライアント証明書要求を促す。空も可）。Shumon と統合を検討する価値があるかもしれない。→ Yaroslav: SPIFFE/WIMSE 界隈で DANCE は事実上未知。
• Shumon Huque: IoT 空間に DANCE 実装がある（AFNIC が LoRaWAN 向け）。統合可否は draft を読んでから。
• EKR: TLS で mTLS を可能にする draft はこれが少なくとも2つ目（mTLS flags draft がある）。両者の joint semantics が不明で、同時受理もできない。進めるなら WIMSE 名ではなく「クライアント証明書を提示できる」一般拡張として、提示可能なリストと1つだけ選ぶ明確なセマンティクスを持たせる rework が必要。→ mTLS flags extension draft は自然消滅の方向（flags そのものの draft は残る）。
• Daniel Migault: 3GPP で活用できるので整合を取りたい。
• Kyle: 一般的機構であるべき。単に「クライアント証明書に応答する用意がある」以上の追加情報を開示する点は懸念。ECH は保護手段として実用的とは限らない。

Shumon との調整を経て、次回 IETF 前に採択検討の可能性。

5. Supplemental Authentication in TLS 1.3 — draft-rosomakho-tls-supplemental-auth-00

主ユースケース: エンタープライズ VPN／ZTNA でのユーザ証明書＋デバイス証明書。デバイス証明書は「会社管理端末である」ことの証明で、UEM/MDM が管理端末の証跡として証明書をトラストストアに配置するのが業界の常套。しかし現行の VPN クライアントはこれを独自方式で実装しており、秘密鍵の所持証明なしに帯域内で証明書を送る（誰でも偽装可能）、あるいはサーバが nonce を送り署名させる（リレー攻撃・タイミング攻撃に脆弱）といった品質。

副次: WIMSE で hostname 証明書（Web PKI）と X509-SVID の両方を提示したい。複数 hostname 証明書（プロキシ↔CDN で同一 HTTP/3 チャネルを複数 origin に使う）。さらに PQ/T・PQ/PQ の代替解。

設計: ClientHello に supplemental_certificate_requests 拡張（CR 拡張のリストで制約可能）。サーバは Certificate に supplemental_certificate フラグを立て、Finished の直後・application data の前に追加の Certificate/CertificateVerify/Finished フライトを送る。追加フライトは application traffic secret で暗号化され、transcript は ClientHello…server Finished ＋ 直前の supplemental フライトを継続。クライアント側も対称（ただし主 Certificate が前提）。鍵スケジュールもハンドシェイクメッセージのフローも変更しない点を利点として主張。post-handshake authentication と異なり両方向に適用でき、application data 開始前に全認証コンテキストが揃うので HTTP/2・QUIC の多重化との相性問題が起きない。追加 RTT もなし。

議論はおおむね批判的

• Usama: RFC 9261/9266 で足りるのでは。「アプリの変更が必要」というが shim 層を挟めばよい。→ Yaroslav: 本提案自体が TLS ライブラリ側の shim であり、application protocol の変更を要さない点が違う。
• Jonathan Hoyland: 「pause 拡張で1ビット立てて『証明書が揃うまで待て』とし、exported authenticators を使う」で同じことができるのでは。exported authenticators は既に RFC 化され形式解析済み（自身の博士論文4章）。本提案は新たに形式解析が必要になる。
• Andrei Popov (Microsoft): application data を送れない以上、これはハンドシェイクの一部であり「ハンドシェイクを変えない」という主張は成立しない。exported authenticators で同じ問題は解けるし、post-handshake auth をサーバ側に一般化するのも難しくない。
• Alicja Kario: サーバ側は恐ろしい。複数 identity が要るなら1枚の証明書に入れてサーバに配り、アプリ側で両方を検証させるべき。エンタープライズならそれができるはず。クライアント側の2 identity（ハードウェア＋ユーザ）の必要性は理解するが、「ハンドシェイクを変えていない」には同意できない。post-handshake auth 完了までデータを受け付けないのはアプリ層のポリシー判断で実現できる。
• プロキシ/LB: TLS を終端した場合に追加証明書をバックエンドへどう渡すか。TLS ライブラリ API の拡張が必要で、インフラ全体の対応が要る。
• Viktor: raw public key に適用されるのかを文書で明示すべき。片方 RPK・片方 X.509 の混在は？ → 現状は証明書のみ。
• Guilin Wang (Huawei): PQ 移行の代替としても使える。IPsec WG に multi-authentication という類似 draft がある（認証方式の数をネゴシエート）。
• Dennis Jackson: PQ 用途としては非常に良くない方向。レイヤも機構も間違い。WG がこの領域で何かやるなら exported authenticators ベースにすべきで、それなら PQ PAKE で追加ラウンドトリップが要るケースも一緒に解ける。
• Hannes: ユースケースの実在確認と解法は別問題。exported authenticators は application 層という選択自体が間違いだったと考える。HTTP の人々も使っていないのが証拠。

Sean の締め: 反対した人たちと話して、嫌がられない形にできるか探ること。

6. PQC Continuity — draft-sheffer-tls-pqc-continuity-02（Yaron Sheffer, Tiru Reddy）

移行期には多くのクライアントが従来証明書と PQC 証明書の両方を受理する状態が長く続き、能動的攻撃者が PQC 証明書を剥がして従来のみに落とす rollback が可能で、クライアントは検知できない。提案は TLS 拡張でサーバが一定期間 PQ 資格情報を提示することをコミットし、クライアントがキャッシュして検証する TOFU ベースの緩和策（完全な修正ではない）。

-02 の変更: OpenSSL で PoC 実装。クライアント証明書対応は複雑さに見合わないと判断して削除しサーバコミットのみに。キャッシュキーを RFC 9525 identity＋ポート番号＋TLS/DTLS の別で明確化。特定アルゴリズムではなく「PQC であること」のみをキャッシュ（アルゴリズムはまだ成熟していないため切替可能に）。チェーン全体が PQC であることを要求し、混在チェーンは明確に拒否。

未解決: Ilari が指摘した Merkle Tree Certificates。証明書チェーンがない場合に「PQC 性」をどう定義するか。

議論

• Richard Barnes: オンラインの CRQC が必要な攻撃モデルか。→ Yaron: 否。オフラインで ECDSA を破って証明書を作っておき、後から使えばよい。
• EKR: IETF 125 では「リストで実際に展開意向があるか確認する」となったが起きていない。誰が展開するのか。→ Yaron: 自前 PoC 以外は把握していない。→ EKR「それで問いへの答えは出た」。Yaron 自身も「産業的にはまだ早い」。
• David Benjamin: ダウングレード保護の問題自体は本物で、これは HSTS の一種。ただし TLS は低レイヤすぎる。HTTP では scheme/host/port がほぼ origin だが cookie は origin をまたぐので includeSubDomains ビットが要り、さらに文脈間の相関を避けるため状態のパーティションも要る。これはアプリ層の問題で、HTTP・メール等で個別にやる必要はあるが、その分ニーズを反映できる。MTC も「アプリが PQ バケットと見なすか」で自然に答えが出る。HSTS ベースの提案を見たい。→ Yaron: HSTS は HTTP が下層を意識する層違反で理想的でもない。→ David: こちらは別方向の層違反。HTTP クライアントの実務者としては HTTP ベースの方がはるかに実現可能性が高い。
• Dennis Jackson: David に同意。大半のアプリには HTTP レベルの機構が望ましい。ただしそれがない世界で何かが必要なら、この draft は正気を失ってはいない。
• Usama: 6月9日にも出した指摘だが、なぜ PQ だけが特別なのか。TLS WG は過去にも移行を経験している。→ Yaron: 平文→TLS（＝HSTS）以来の「下位を破れる」タイプの移行だから。1.2→1.3 では「1.2 を破れる」問題はなかった。
• Guilin Wang: PQC コミットメントは具体的に何を格納するのか。→ 現 draft では PQ 署名アルゴリズムの特定リストに基づく。

7. PAKE 拡張 — draft-ietf-tls-pake（Chris Wood、金曜）

仕組みの復習: ClientHello で identity pair（client/server）と1つ以上の PAKE メッセージを提示 → サーバがサポート集合と identity の存在確認からアルゴリズムを選択して応答 → クライアントが完了し、導出した共有秘密を既存の (EC)DHE と並んで鍵スケジュールに注入。

• 証明書ベース認証との併用は可（以前は排他だったが不必要に硬いとして緩和）。PSK との併用は明示的に禁止。
• 登録済みアカウントの列挙攻撃対策として、クライアントレコードが見つからない場合にサーバが応答をシミュレートするオプション（全ユースケース向けではない）。

制限

• 複数ラウンドの PAKE（CPaceOQUAKE / CPaceOQUAKE+）は既存の TLS の形に収まらず非対応。
• Augmented PAKE の key confirmation を運ぶスロットが TLS 1.3 ハンドシェイクにない → PAKE 由来の key confirmation を落とし、TLS Finished を confirmation として利用。直感的には成立するが形式解析は未実施。

新規: External PAKE

ハンドシェイク外で任意の PAKE（何ラウンドでも可）を走らせて PSK を導出し、RFC 9258 の importer でインポートして通常の TLS を走らせる指針を追加。ImportedIdentity に external_identity・context・target_protocol・target_kdf を持たせ、internal PAKE と同じ application context を使う。運用上は PAKE 用ポートと TLS 用ポートを分けるなどの識別手段が要るが、P2P のように両端を制御できる場面では障害にならない。

新規: 形式解析 — https://github.com/chris-wood/tls-pake-model

ECH の公開 ProVerif モデルを fork。相互認証（replay を考慮したセッション鍵と identity の合意）、鍵秘匿性、前方秘匿性、通常の TLS 性質の非回帰を実証。

制限: 高エントロピー秘密を入力と仮定（辞書攻撃は非モデル、PAKE は正しく動く黒箱と仮定）／サーバシミュレーション・証明書・ECH との合成は未モデル化／augmented PAKE の per-client 秘密はパスワードに畳み込み。

残作業: 機能組合せのモデル化（証明書認証・PSK・ECH との併用で回帰がないこと）と、client key confirmation を TLS key confirmation で代替した点の計算量的（cryptographic）解析。記号的解析は適切な道具ではないとの認識。この状態で FATT assessment に出す用意ができたとの主張。Chairs は既に FATT へのメッセージを準備中。

質疑

• EKR: レコード層が完全に破られていてもセッション鍵に対する key confirmation は Finished から得られるという理解でよいか → Yes。
• Scott Fluhrer (Cisco): OPAQUE はモデル化されているものと大きく異なる（クライアントが得るのは共有鍵ではなく自分の鍵ペア）。TLS への適合性自体は悪くないかもしれないが、この枠組みでは扱えないので完全に別文書にすべき。→ 現 draft に OPAQUE 統合はない。
• Viktor: PAKE でネゴシエートした後の resumption に懸念はあるか。→ external PSK と同様で特段の差はない。DH は通常どおり行われる（ただし主鍵交換と PAKE は直交で、DH なしの構成もありうる）。
• Usama: 具体的に何を助けてほしいのか → 計算量的解析と、上記の機能組合せ。

8. PQ + T 署名（金曜、55分の集中セッション）

8-0. Chairs の枠組み設定

EKR の発案で「PQ+T 署名をやるかどうか WG の意見を形成し、やるならアプローチを1つ選ぶ」ことを目的に設定。スライドで**「アルゴリズムの話ではない」を3回**強調（スレッドは squelch すると宣言）。数か月前の side meeting ではより多くの選択肢があったが、draft として出てきたのはこの2本のみ。両 draft の authors は敵対関係ではなく、一部は両方に名を連ねている。

8-1. Dual Certificates — draft-yusef-tls-pqt-dual-certs-03（Rifaat Shekh-Yusef, Hannes Tschofenig ほか Tiru Reddy, Mike Ounsworth, Yaroslav Rosomakho）

動機: 一部の管轄・顧客が hybrid 署名を要求しており、もはや選択の問題ではない。Composite の置き換えではなく、異なるユースケースに対する別モデル。

対象: エンタープライズ／産業 IoT。Web は重要だが唯一のユースケースではない。具体例として Ciena の光システム（データセンター間、ルータ↔光システム間で長寿命の mutual PQ/T TLS 1.3 チャネルを張り、そこから鍵を mint して専用ハードウェアで光トラフィックを暗号化）。両端を同一組織が管理する。

PKI の比較: composite では traditional / composite / PQC の3系統の PKI が必要で、CA と EE の組合せを混在させるとさらに複雑化。dual なら traditional と PQC の2系統で、hybrid モードでは証明書を2枚出す。ただし明確に分離された PKI 階層のみが対象で、mix-and-match 階層はカバーしない。

仕様: Certificate の構造は変更なし。空の CertificateEntry を区切りとして2つのチェーンを連結。CertificateVerify も構造は変更せず（IETF 123 のフィードバックを受け、新メッセージを作る案は撤回）、新 SignatureScheme（ecdsa_secp256r1_sha256_mldsa44、ecdsa_secp384r1_sha384_mldsa65）を定義。

signing-input    = Transcript-Hash(Handshake Context, Certificate)
first-signature  = Sign(traditional-private-key, signing-input)
second-signature = Sign(pq-private-key, signing-input)
signature        = uint16(len(first-signature)) || first-signature || second-signature

質疑

• David Benjamin: これは SAAG で議論した問題（サーバが更新されない前提）とは無関係。サーバ更新を要するため。→ Hannes: SAAG は Web 中心だった。問題領域ごとに異なる解を記述する文書があるとよいのでは。
• Jonathan Hoyland: 1つ目の署名の出力を2つ目の署名入力に含めないのはなぜか。→ Rifaat: 検討はした。Tiru: nested signature と concatenation について PQUIP で解析があり、同じ性質（weak non-separability）が得られる。重要なのは、traditional 側の署名が PQ の EE 証明書・中間証明書を含む transcript 全体を対象にしている点で、逆も同様。→ Jonathan: 自明ではないので後で確認する。
• Andrei Popov (Microsoft): サーバ更新が必要なのに backward compatibility とはどういう意味か。→ Hannes: 未更新の実装が対応できるという意味ではなく、既存インフラを段階的に PQC へ移していける（サーバを更新→ PQC 証明書を発行→試験→対象を拡大）という意味。
• Usama: 2つの鍵の関係は？同一サーバのものであることをどう保証するのか。1つ目の署名出力を2つ目の入力にする案には自分も賛成。PQUIP の解析へのリンクが欲しい。→ Hannes: Certificate メッセージに両チェーンが含まれ、transcript 全体に対して署名するので間接的に結合される。
• EKR: signature_algorithms に載るのに証明書の署名には使えず CertificateVerify 専用、というのは拡張の通常の意味と異なり読んでいて紛らわしい。動作はするだろうが。
• Viktor Dukhovni: 率直に言えば「hybrid 証明書を出せない／出したくない CA のもとでの hybrid 署名」。本質は CA をループから外し、2つの部分を別々にプロビジョンできること。ダウングレードや移行の問題は解決しない。→ 著者側もダウングレードは別文書（Tiru が共著の PQC Continuity）と認める。
• Bob Beck: 更新済みサーバが未更新クライアントにも提供し続けるには証明書ネゴシエーションが要る。→ 著者: 単一証明書へのダウングレードを含む。クライアントの offer で決まるので、traditional のみを offer するクライアントには traditional で応答する。

8-2. Composite ML-DSA — draft-reddy-tls-composite-mldsa-10（Tiru Reddy ほか Tim Hollebeek, John Gray, Scott Fluhrer, Daniel Van Geest）

LAMPS で約7年、draft-ietf-lamps-pq-composite-sigs は RFC Editor queue にある。PQC と従来の署名・公開鍵をアトミックな操作として扱い、両方の検証が成功した場合のみ検証成功。defense in depth と、PQC 署名アルゴリズムにバグ・脆弱性が見つかった場合の耐性、そして規制上の要求に応える。

TLS 統合: 既存の signature_algorithms と signature_algorithms_cert のみを使用。新しいハンドシェイクメッセージも拡張も区切り子も不要。composite ML-DSA は opaque な署名アルゴリズムとして扱われ、TLS はハッシュ関数を選ばない（ハッシュはアルゴリズム内部）。context string は空（TLS が RFC 8446 §4.4.3 のプロトコル固有 context を既に持つため）。

制限: RSA PKCS#1 v1.5 の組合せは signature_algorithms_cert のみで許可し、CertificateVerify では使わない。

アルゴリズム選定: LAMPS の composite 組合せ ∩ TLS 1.3 推奨の従来署名アルゴリズム。Brainpool 系を除いた全ペア。削減の余地はある。

セキュリティ: EUF-CMA（偽造には両方の構成要素を破る必要）。SUF-CMA が追加するのは「既署名メッセージに対する別の有効署名の防止」だけで、なりすましには新しい TLS transcript に対する有効署名が必要であり、TLS のハンドシェイク transcript は毎回一意なので TLS には不要。

利点: ワイヤ上は1証明書・1チェーン、検証も1チェーン、取得・更新・デバッグも単一 CA、TLS 側の変更は最小。暗号ライブラリが合成・分解を担い、IPsec・JOSE・SSH と共有されるのでコストは1回だけ。

Nicola Tuveri (Tampere University): 過去1年半、Web シナリオと制約デバイスの mutual TLS の双方で composite ML-DSA をサーバ・クライアント両側に展開してきた実体験として、非常に肯定的。opaque であるおかげで展開が実に簡単で、ライブラリがエンコーディングをサポートし TLS コードポイントがあればそれ以上は要らない（自分たちは引退したコードポイントを流用）。「これは実質もう終わっている」ので、選ぶならこちらは即座に実現できる。

8-3. 議論

• EKR（口火）: そもそもやる必要があるのか。自分が関心を持つ環境では、ML-DSA が破られたと分かればどのみち無効化のための更新が必要になる。かなり限定的なユースケースであり、渋々ならやってもよいという程度。
• Dennis Jackson: 移行／後方互換とヘッジの2つのユースケースに分けるべき。どちらの方式も移行には価値がないと考える。composite はヘッジには価値がありうるが、個人的には乗り気ではない。
• Chris Wood: 既存の古典的な展開に対するヘッジとしての改善を望む人は実在する。composite はそのユースケースに対して圧倒的に単純。例えば raw public key での hybrid 署名を望む実運用があり、これはコードポイントさえあれば解ける。「WG が時間を使うべきか」以前に、IANA へのメール1本で済む話をなぜここで止めているのか。
• David Benjamin: ヘッジ前提で考えると、費用対効果では composite が圧倒的に低コストなので、1つ選ぶなら composite。ただし署名のヘッジ価値は KEM より遥かに低い。遡及的復号がないので、ML-DSA が破れても classical に戻してソフト更新を出せば済む。ヘッジの利点は「更新を取りこぼした relying party」だけであり、公開 PKI では「信頼する人間の選択を誤る」という遥かに高確率の失敗が既にあり、それには結局ソフト更新が要る。したがって多くの PKI では価値はほぼゼロで、鍵を更新可能に保つ外圧がない少数のケースに限られる。かなりニッチ。
• Andrei Popov: 鍵交換アルゴリズムの変更は設定変更で済むが、証明書チェーンの変更はトラストアンカーの展開問題で非常に遅い。だからヘッジが欲しい。方式は composite が望ましく、暗号層の醜さを封じ込めて TLS の API を変えない。少なくともコードポイントが欲しい。
• John Gray (Entrust): 確実に必要。コードポイントは最低限必要だが、TLS の推奨との交差（RSA 1.5 の扱いなど）を書き残すなら draft も要る。
• Hannes: Web ブラウザに関わる人にとっては関心外だろうが、それ以外の展開も存在する。ブラウザ空間の外にあるものが即座に疑われ価値を割り引かれるのはこの WG の慢性的な問題。加えて、アルゴリズムのヘッジ以外に「従来鍵はハードウェア保護、PQ 鍵はそうでない」といった保護レベルの分離という用途もある（これだけでは dual certs の複雑さは正当化できないが、composite は十分単純なので見合う）。
• Rich Salz: 「必要だ」という発言は多いが、示されたユースケースは光リンク越しのデータセンター間で、VPN と同じ TLS over TLS に見える。どう必要なのかの具体例をもっと見ないと賛否を決められない。→ Sean: 一部の管轄が要求している。
• Jonathan Hoyland: PQ 性を無視して、単に証明書が2枚あるとして、目指す性質は何か。両方を破らないとハンドシェイクを完了できないのか、外側だけ破ればよいのか。何をしたいかで変わるのに不明確。（チャットで Usama「両方が破られる必要がある、であるべき」）
• Sophie Schmieg（チャット）: hybrid は PQC への移行手段ではなく、より安全な側と同等の安全性を得るためのセキュリティ機構。この2つの目標を混ぜるのは非常に危険。
• Jonathan Hoyland（チャット）: 内側を外側で署名し、外側が master key へのコミットメントを持つなら、自然に両方の安全性、つまり Sophie の定義より強いものが得られるはず。
• John Preuß Mattsson（チャット）: Web は standalone ML-DSA-44 になりそうで、それは良い選択。より保守的にするなら ML-DSA-65／87 か SLH-DSA が最良の2候補。組合せ爆発を避け PQ/PQ hybrid も可能な非 composite 署名には価値があるが、現提案には納得していない。composite は CFRG を待つべき（CFRG での composite 作業に40人が賛成した）。
• EKR（締め）: 争点は「許されるか」ではなく「WG が時間を使うか」。composite ならごく短時間で済み、実質既に完成している。dual cert 版には膨大な時間がかかる。安価なヘッジが欲しいなら composite 一択。先ほど「渋々」と言ったのは少し不機嫌すぎた。反対はしない。

8-4. 投票結果

質問2が Yes だったため、両方に取り組む場合の順序を問う質問5〜7は実施されず。

結論: 一方のみ、かつ composite ML-DSA に取り組む方向で、chairs がリストで確認する。最後のコードポイント関連の質問は文言をめぐる混乱（「割り当てて進む」なのか「割り当てて採択しない」なのか）で chair が打ち切り、次の議題へ移行した。

Usama からは「スライドのアップロードが遅すぎる。1週間前なら2案を比較・分析できた」との異議（chairs は「両 draft 自体は長く公開されている」としつつ指摘は受け入れ）。

9. XOF ベース鍵スケジュール — draft-sullivan-tls-xof-ciphers（Nick Sullivan）

「TLS 1.4 を発表します」→「冗談です。TLS 1.3 に新しい KDF を入れただけ」という導入。connection = cipher suite (RFC 9846) + KDF (this document)。

不変: ハンドシェイクメッセージの表現とフロー／レコード層／cipher suite・AEAD・状態機械／鍵スケジュールのステージ・名前付きシークレット・leaf・checkpoint。

変更されるのは KDF のみ: HKDF over SHA-2 → 単一の Keccak permutation。schedule_profile 拡張で選択し、拡張がなければ通常の RFC 9846 ハンドシェイク。

permutation 呼び出し数の推移

SHAKE256 は 24 ラウンド／呼び出しで計 936、TurboSHAKE256 なら 12 ラウンドで計 468（ただし EUF-CMA の解析は未了）。

deck function: XOF の可変長入出力に対する既知のパターン（Doubly-Extendable Cryptographic Keyed function、ここでは unkeyed 利用）。TLS 1.3 に必要な4操作は Init（"tls13 " を framing した新しい sponge）、Absorb（tag 付き入力を1つ折り込む、出力なし）、Derive（clone → context → label を absorb → 1回 squeeze）、Ratchet（= Init(Derive(D, "derived"))、幹を squeeze して次段の種にする）。early/handshake/main secret は具体的なデータではなく deck の状態となり、leaf ごとに clone、段の境界で Ratchet。TLS 1.3 が暗黙にしていた Ratchet を明示的に名付けた形。

根拠: TLS13KS（Brzuska et al., ASIACRYPT 2022）は SHA-2 を塊としてではなく役割で分解して解析している（Hash=衝突耐性、Extract=どちらの入力で鍵付けしても PRF、Expand-Label=PRF、MAC=EUF-CMA、Derive-Secret=PRF）。置き換えは解析が依拠する性質さえ保てばよく、sponge は indifferentiability（BDPV 2008）により 2^256 まで random oracle であり、単一の oracle が全役割を同時に満たす。injective framing により異なる導出は異なるクエリになる。

deck Derive は HKDF ではない: HKDF-Expand-Label が label→context の順なのに対し、deck Derive は transcript→label の順で全フィールドを長さ prefix で framing する。injective なので順序自体は安全性に影響しないが、これにより TH_SF を共有する3つの leaf（c_ap_traffic / s_ap_traffic / exp_master）が transcript を1回 absorb してから fork できる。HKDF は label が先に来るため leaf ごとに TH_SF を再ハッシュせざるをえない。

transcript hash: SHA-256（32オクテット固定）→ SHAKE256(prefix, 512)（64オクテット、任意長）。5つの checkpoint（TH_CH0/TH_CH/TH_SH/TH_SF/TH_CF）で cipher suite に依存しないため、クライアントは事前計算できる。

ML-KEM/ML-DSA が既に Keccak permutation 上で動くため、PSK 専用・純 PQ 展開では SHA-2 が最後の hard dependency だった、というのが動機。証明書側には SHA-2 が残る。

-00 へのメーリングリストレビュー（Markku-Juhani Saarinen, Thom Wiggers, Joan Daemen, Ilari Liusvaara）

• 4操作への書き換えで構造的に解決した項目: leaf あたり Derive 1回（3つの別 label ではなく）／鍵スケジュールが cipher suite を束縛しない／各 leaf が leaf で transcript を束縛し幹は束縛しない／nested prefix 構文のない flat な Derive。Saarinen は回数（39/117/156）を独立に Go で検証し、優位性が Keccak 由来ではなく構造由来であることを確認。Wiggers の "15.5" の指摘も解消。
• 決定（現状維持）: label は TLS 1.3 と同一のまま／finished_key は RFC 9846 の2層 derive-then-MAC を、1層で足りる証明が出るまで維持。
• 却下: Ilari の「Ratchet ではなく clone でよい」は、TLS13KS の前方秘匿性のために境界で状態を削除する必要があるため却下（accumulator を持ち回ると可逆なので後の compromise から再導出できるが、一方向 squeeze ならできない）。Keccak AEAD は後続作業とし、CFRG が先。
• 未解決: TurboSHAKE256（12ラウンド）は利得を倍にするが TurboKMAC256 に EUF-CMA の証明がない（Daemen は12ラウンドを十分な余裕と見ており、SHAKE256 既定はこれに依存しない）／hybrid 鍵交換で各構成要素を個別に absorb する現設計と、group が hybrid かを判別できないスタックの都合／"th" と "out" のタグが injective framing により冗長ではないか／Daemen の overwrite-duplex 提案は Lemma 2 の再帰が One-Shot Equivalence を壊し、生の Keccak-p（Go 標準ライブラリ外）と |K| ≤ ρ の制約を要する。

質疑

• Usama: 記号的解析は理想的一方向性関数を仮定するので有用でない可能性が高く、ここで必要なのは計算量的（暗号学的）解析では。→ Nick: どんな解析でも歓迎。Python と Go で実装した概念実証段階。（チャットで Jonathan Hoyland「Tamarin の証明はほぼそのまま通ると思う」）
• Quynh Dang (NIST): これをやるなら NIST が精査し、最終仕様が我々の暗号標準を満たすか判定する。仮に仕様上は満たさなくても安全と評価されれば通す道を探す。SHA-2 での準拠経路を望む人はそれで構わない。全面的に支持する。
• Dmitry Belyavsky (Red Hat): ベンチマークは。→ テストベクタのみ。Markku がリストで「非常に速い」と報告。
• John Preuß Mattsson: PQC がすべて SHA-3 を使う以上、TLS で SHA-3 ファミリを選べるのは良い。deck が正しい選択であり、TLS はこれに取り組むべき。
• EKR: (1) ここは適度に保守的でよい。Amdahl の法則で、PK 演算が既に高価なので最後の数サイクルを絞っても得は少ない。156→39 は大きいが 39→20 の価値は不明。(2) TLS 拡張でネゴシエートするのは正しくないのでは。cipher suite は既に transcript hash を名指ししているのだから、「SHA-3 を使うならこの方式」と決めればよい。→ Nick: 元はその設計だったが Martin Thomson の提案で KDF レジストリ側に分離した（現在2値しかないので SHAKE/TurboSHAKE 用に2つ追加するだけで済み、全 cipher suite の SHA-3 版を作るより増殖が少ない）。→ EKR: それでは cipher suite 内の SHA-256 が意味を持たなくなり最悪。cipher suite 名を付け直すのが正しい。リストで継続。

10. ECH の実測 — Encrypted Client Hello: An active measurement perspective（Jonas Mücke, TU Dresden ほか Konstantin Gasser, Matthias Wählisch, Thomas C. Schmidt）

手法: DNS の ECH 情報に依存せず、top list のドメイン名を outer SNI に入れた GREASE ECH 付きハンドシェイクを行い、HelloRetryRequest の RetryConfiguration から実際の設定を取得。それを使って本番の ECH 接続を行う。1年以上集約。入力が top list ベースなので全展開を網羅するわけではない。

結果

• 5.5M ドメインが ECH 有効。second-level domain 単位では 4.1M。うち 34% は DNS に ECH 設定を持たない（最大は Meta）。
• Meta の検証: iOS 端末のトラフィックを採取し、TCP+TLS と QUIC の両方で ECH 拡張を観測。config ID と public name が測定で得た RetryConfiguration と一致したため実 ECH トラフィックと判断。ただし全リクエストに ECH 拡張が付くわけではない（全体を GREASE していない）。
• 展開の推移: Cloudflare が圧倒的、次いで Meta（graph.facebook.com）。その他は合計でも 250 second-level domain 程度。ECH public name は 3k 観測されるが SLD は 250 のみ（1つの展開が *.example.com 形式のランダムサブドメインを単一 SLD で使っているため）。CDN が全顧客に一斉に ECH を有効化するような大幅な増加は観測されていない。
• 典型的な設定: ほとんどが1 config だが最大30の展開もある。大規模展開でローテーションしているのは Cloudflare のみ。maximum name length が private ドメイン長ではなく ECH public name 長と一致することが多く、このオプションが十分理解されていない可能性。KEM は HPKE_KEM_X25519_HKDF_SHA256、cipher suite は AES_GCM_128_HKDF_SHA256 がほぼ全て。
• grace period: Cloudflare は DNS から鍵を削除し RetryConfigurations にも載せなくなってから 4〜5時間は当該鍵を受理し続ける。古い設定を持つクライアントが RetryConfiguration 経由の追加 RTT を払わずに済み、鍵ローテーション障害の修復時間も確保できる。
• 任意の public name の受理: 検閲耐性と ECH 検知耐性は上がるが、大規模展開はどこも受理していない。domain fronting を防ぐため、かつクライアントが public name の証明書を検証する必要があるため retry 機構が壊れるため。代替として draft-sullivan-tls-signed-ech-updates を挙げている。
• レイテンシ: ECH 接続はわずかに遅い。自前の vantage point だけでなく住宅網の CAIDA Ark ノードからも同様。
• 安定性: 低下は見られるが大半は名前解決の失敗によるもので、ECH 展開自体は概ね安定。
• 分類（backup）: プライバシー上の便益が限定的なもの、第三者ドメインに便乗する freeloader、テストドメイン、詐欺ドメイン。小規模展開の private ドメイン集合は 55 以下。

ツールは hackathon 作の echtool、および ech.understanding-quic.net で試用可能。

コメント

• Kyle: 主要アプリの1つで ECH を広く実運用中。動作も性能も良好で、近く共有できる見込み。他社にも推奨したい。
• Gianpaolo: KPI として client-facing server の多様性を加えるべき。現状は事実上1つしかなく特権的観測点になっているが、展開が広がればプライバシーが向上する。

次のアクション一覧