要約

  • RFC 10015は、TLS/DTLS 1.2でクライアントがFFDH、FFDHE、RSA鍵交換スイートを提示すること、サーバーがそれを選択することを禁じる。静的ECDHは絶対禁止ではなくSHOULD NOTである。
  • 境界は版と機能に依存する。TLS/DTLS 1.3のFFDHEは許容され、RSA証明書で許可されたECDHEを認証することもRSA鍵交換とは別である。
  • IANAのDやRFCの発行は実行中設定を書き換えない。終端台帳、肯定・否定テスト、失敗理由、期限付き例外、ロールバック、ドリフト検知がそろって初めて退役を証明できる。

最初の障害報告は「証明書エラー」だった

夜間変更の翌朝、古い収集端末だけがAPIへ接続できなくなった。TLS 1.2は許可されたまま、サーバー証明書も同じで、有効期限にも問題はない。監視担当は証明書更新の失敗を疑った。

実際には、その端末がTLS_RSA_*しか提示していなかった。

RFC 10015は2026年7月にStandards Trackとして公表され、TLSまたはDTLS 1.2でRSA鍵交換スイートをクライアントが提示せず、サーバーが選択しないことを要求する。したがって今回の拒否は、新しい境界が働いた結果かもしれない。

しかし、依存端末を事前に把握せず、所有者も代替計画もないなら、正しい暗号判断がそのまま正しい移行になるわけではない。古いスイートを戻せば業務は復旧するが禁止経路も復旧する。拒否を放置すれば規範には沿ってもサービス責任が空白になる。

ここで必要なのは、成功率ではなく決定経路の説明である。

バージョン表示は鍵の作り方を示さない

TLS 1.2の暗号スイートには、認証、鍵交換、対称暗号、完全性保護が組み込まれている。「TLS 1.2」という表示だけでは、共有秘密をどの方式で作ったか、鍵が一時的だったか、どのグループを用いたか、どの装置が選択したかは分からない。

RFC 10015はDH系を四つに分ける。FFDHは有限体上の非一時的Diffie-Hellmanで、静的なDH公開鍵が証明書に入る。FFDHEはハンドシェイクで一時公開値を送り、証明書でそれを認証する。ECDHとECDHEは楕円曲線上で同じ静的・一時的な差を持つ。

TLS/DTLS 1.2に対する規範は次の通りである。

  • 非一時FFDH：提示も選択もMUST NOT。
  • FFDHE：提示も選択もMUST NOT。
  • RSA鍵交換：提示も選択もMUST NOT。
  • 非一時ECDH：提示も選択もSHOULD NOT。

さらに、固定DH証明書型のrsa_fixed_dh、dss_fixed_dh、rsa_fixed_ecdh、ecdsa_fixed_ecdhは、クライアントが使わず、サーバーが受け入れないことが推奨される。これらの識別子は1.2以前にだけ適用される。

MUST NOTとSHOULD NOTを同じ赤色に塗ると、判断記録が壊れる。静的ECDHを残すなら強い特殊事情と期限が必要だが、RFCはRSAと同じ絶対禁止にはしていない。一方、RSAやFFDHEを優先順位の末尾へ移すだけでは不十分である。他に共通スイートがなければ選べる状態は、経路が生きている。

名前だけで消すと二つの誤作動が起きる

一つ目は「RSAをすべて無効化」である。RSA公開鍵の証明書は、ECDHEで作った一時的な秘密を認証する署名に使える。これは禁止されたRSA鍵交換ではない。証明書アルゴリズムだけを条件にすれば、許された経路まで落としてしまう。

二つ目は「DHEをすべて無効化」である。RFC 10015は、TLS/DTLS 1.3のFFDHEは1.2について列挙した問題を共有せず、引き続き提示できると明記する。文字列一致で全バージョンを処理すると、限定された退役をアルゴリズム族全体の禁止へ変えてしまう。

したがって判定単位は、証明書名やプロトコル版の一項目ではない。終端、読み込まれた設定、クライアントの提示、サーバーの選択、最終結果を一つの記録として扱う必要がある。

TLS 1.2のFFDHEが「一時鍵だから安全」で済まない理由

一時鍵は長期認証鍵の漏えいから過去セッションを守るために重要だが、グループ選択まで自動的に安全にはしない。TLS 1.2では有限体グループの交渉が弱く、サーバーが独自グループを提示する例が広がった。クライアントは接続中に任意グループの性質を実用的に検証できず、危険または非対応のグループから別の受容可能なものへ切り替える明確な経路もない。

RFC 7919は名前付きFFDHEグループを導入し、広い互換性を求めて小さなサイズへ引かれる運用事情を記録した。RFC 10015は、1024ビット群の残存、小部分群、標準群に対する大規模事前計算の使い回しを退役理由として整理している。

スイート名の「E」も実装を保証しない。一時秘密が再利用されればRaccoon型のタイミング漏えいが成立し得る。非一時FFDHは、厳密な定数時間対策がなければ同じ性質を構造的に抱える。決定はDH一般への評価ではなく、TLS 1.2の交渉、検証、互換性、秘密管理を組み合わせた評価である。

RSA鍵交換は将来の漏えいを過去へ運ぶ

TLS 1.2のRSA鍵交換では、クライアントがプレマスター秘密を作り、サーバーのRSA公開鍵で暗号化する。この方式には前方秘匿性がない。通信が保存され、後日秘密鍵が入手されれば、過去の内容が解読対象になる。

もう一つはBleichenbacher型オラクルである。不正なRSA暗号文へのエラー、時間、応答の差を観測できると、秘密を段階的に回復できる。ROBOTやDROWNのような後続研究は、対策を完全に同一挙動へする難しさと、同じ攻撃族が戻る性質を示した。

影響は横にも広がる。(D)TLS 1.2には便利な鍵ドメイン分離がなく、複数終端が一つのRSA秘密鍵を共有する場合がある。最も弱い終端のオラクルが、別チームのサービスや過去通信まで再評価させる。証明書期限だけでなく、秘密鍵指紋の再利用範囲を把握しなければならない。

Dは共有記録であって停止命令ではない

RFC 10015はTLS 1.2、DTLS 1.2、BCP 195を含む17のRFCを更新した。IANA TLS Parametersでは対象スイートと証明書型のRecommended欄がDになり、新RFCが参照に加わった。RFC 9847は、この記号を新規実装または新規配備に推奨しない意味として定める。

この記録は、実装者、調達者、運用者が同じ分類を参照するために必要である。しかし、IANAの表はプロセスのメモリーを書き換えない。

表と実行の間には、TLSライブラリ、ビルド機能、暗号プロバイダー、アプリの上書き、環境変数、プロキシ、ロードバランサー、CDN、機器ファームウェア、地域別テンプレートがある。リポジトリの設定が正しくても、sidecarが別の文字列を渡すかもしれない。オリジンが安全でもエッジが独自に交渉する。

標準と設定差分は意図の証拠である。読み込まれた設定と実ハンドシェイクが実行の証拠になる。

変更前に交渉台帳を作る

まず決定点を列挙する。公開リスナー、内部API、外向きクライアント、DTLSサービス、サービスメッシュ、プロキシ、CDN、アプライアンス、組み込み端末である。各項目に所有者、ライブラリと暗号プロバイダー、実効スイート、バージョン範囲、SNI/ALPN、証明書用途、鍵再利用、地域、相手集団を結び付ける。

次に動作基準を採る。成功について版、スイート、鍵交換、選択した終端、アプリ到達を記録する。失敗は「共通スイートなし」「グループ非対応」「証明書拒否」「版不一致」「トランスポート後のアプリ失敗」の最初の境界で分類する。

テストは肯定と否定を対にする。

  • 1.2でRSAまたはFFDHEしか提示しないクライアントは失敗する。
  • 許された一時交換を持つ1.2クライアントは成功する。
  • TLS 1.3は利用可能なままで、許容するFFDHEも残る。
  • 新旧を混在提示した場合、意図した新経路を選び、隠れたフォールバックをしない。

テストは各終端層で繰り返す。オリジンの結果はエッジを証明しない。展開も所有権に沿って分割し、一つのリスナークラス、地域、プロキシ層、端末群ごとに進める。前後の設定指紋、サンプルハンドシェイク、失敗分布、アプリcanary、限定ロールバックを保存する。

完了条件は「設定を配った」ではない。「禁止経路が観測から消え、許可経路が継続し、実効設定が戻っていない」である。

動いているコードにしか示せない事実

Heng LuのRunning-Code Primacyは、宣言と実行を分離する。RFCは検証条件を書ける。IANAは共有記録を持てる。しかし本番のハンドシェイクを代行することはできない。

最小初期仕様と将来判断の局所化も、この境界を中央命令か無秩序かという二択にしない。共通層は互換でない組み合わせを決定的に定める。各参加者は台帳、順序、置換、隔離、例外、ロールバックを自ら決め、その結果に責任を負う。

局所判断は、禁止されたスイートを独自に「適合」と呼ぶ権利ではない。移行費用の主体、範囲、終了条件を明示する権限である。RFC 10015が境界を描き、各終端の実効状態がその境界を現実にする。