要約

  • RFC 10015はTLS 1.2とDTLS 1.2について、有限体Diffie–Hellmanの複数方式と静的RSA鍵交換をクライアントが提示せず、サーバーが選択しないようMUST NOTで定めた。一方、静的ECDHと固定DHクライアント証明書型はSHOULD NOTであり、同じ強さではない。
  • IANAのDは標準上の判断を示す証拠であって、実装、実効設定、再読込、全終端点への展開、提示・選択の挙動、例外の失効を示す証拠ではない。無効化を名乗るには、各層を結ぶ「非推奨化クローズ証票」が要る。

中央のポリシーは更新済みだった。設定リポジトリにも禁止項目はなかった。それでも、別管理のUDP終端装置では旧イメージが動き続けていた。監査画面の緑色は、そこへ到達した検査結果ではなく、レジストリの変更を読み取っただけだった。

この食い違いは、RFC 10015の欠陥ではない。同文書はIETFのStandards Trackとして、TLS 1.2およびDTLS 1.2の旧式鍵交換に何を許さないかを定める。製品の採用率を測定せず、特定事業者の設定を評価せず、稼働プロセスに変更を配布するものでもない。標準は判断基準を与えるが、運用結果まで代行しない。

むしろ危険なのは、機械可読な規範情報の扱いやすさである。IANA表の値を取り込み、ルールに変換し、ダッシュボードを着色することは簡単だ。だが、その行から一回のハンドシェイクまでには、ライブラリが持つ能力、製品既定値、ローカル設定、設定の生成物、プロセスの読込状態、TLS終端の所在、クライアントの提示内容という独立した判断点が並ぶ。

「古いTLS」を一括りにしない

RFC 10015の規範語は一様ではない。TLS 1.2とDTLS 1.2における非一時的な有限体DH暗号スイートについて、クライアントは提示してはならず、サーバーは選択してはならない。これは MUST NOT である。同じバージョンの一時的DHEにもMUST NOTが適用され、静的RSA鍵交換も禁止側に置かれる。

静的ECDHは SHOULD NOT のままである。文書が対象にする固定DHクライアント証明書型もSHOULD NOTだ。例外には十分な理由と審査が必要だが、MUST NOTからの逸脱と同じ意味ではない。すべてを「deprecated」の一語へ潰す管理台帳は、例外の可否を判断するための情報まで捨ててしまう。

プロトコル版も事実の一部である。RFC 8996はすでにTLS 1.0と1.1を非推奨とした。RFC 5246はTLS 1.2を定義し、RFC 8446はTLS 1.3の鍵共有を再設計した。RFC 10015はTLS 1.3でのFFDHEを明示的に許している。TLS 1.2固有の問題を根拠に、すべての版の有限体DHEを排除するのは誤読である。RFC 7919は有限体グループのネゴシエーションを理解する背景として残る。

「静的RSA鍵交換」は「RSAを一切使うな」という意味でもない。RSA証明書やRSA署名を使いながら、静的RSA鍵転送を用いない構成は成立する。証明書台帳でRSAという文字を探しても、対象の鍵交換経路をサーバーが選べるかどうかは分からない。

区別の背景には具体的な危険がある。前方秘匿性がなければ、長期鍵の漏えいが過去の通信へ遡及する。有限体DH鍵の再利用はタイミングやグループ選択の問題を招き、ECDH鍵の再利用は無効曲線、サイドチャネル、フォールト攻撃の面を広げる。静的RSAはBleichenbacher系の問題を繰り返し背負い、鍵再利用やプロトコル横断の危険も生む。RFC 9325とRFC 9847が示すのは、古い相互運用性を永久の免許にせず、蓄積した知見に運用指針を追随させる姿勢だ。

Dが証明する範囲

IANA TLS Parametersでは、対象暗号スイートと4つのClientCertificateType識別子にDが付き、RFC 10015が参照される。Dはdiscouragedを意味する。具体的にMUST NOTかSHOULD NOTかは、参照先の規範本文で決まる。

従ってDが証明するのは、公開レジストリにおける推奨状態である。コード検査、調達基準、移行チケットを始める根拠にはなる。しかし、ライブラリが機能を削除したこと、製品の既定値が変わったこと、現場設定から消えたこと、プロセスが新設定を読んだことは証明しない。

全SNI、リスナー、プロキシ、ロードバランサー、地域エッジへの反映も証明しない。クライアントが提示をやめたか、サーバーが選択しなくなったか、例外経路やロールバック用イメージが復活させないかも別問題である。それぞれ所有者も有効期限も違う。

能力、提示、選択、観測

運用記録には最低でも四つの列が必要だ。能力はコードが鍵交換を実行できる状態、提示は特定のクライアントがHandshakeで送った候補、選択はサーバーが実際に選んだ結果、観測はスキャナーやテレメトリーが見た範囲を指す。

能力が残っていてもポリシーで全提示を止められる。設定に名前が残っていても上位規則により選ばれない場合がある。観測ゼロでも、SNI別の経路、UDP上のDTLS、内部エッジ、条件付き互換ルートを検査していないかもしれない。

対象方式だけを提示して拒否を期待する負試験は、現代的な通常クライアントの接続より強い証拠になる。それでも結論は、到達したアドレス、ポート、トランスポート、SNI、時刻、設定版に限られる。RFC 9147のDTLS 1.3を含め、TLS/TCPの検査結果をDTLS/UDPへ流用してはならない。

非推奨化クローズ証票

各サービス露出面に 非推奨化クローズ証票 を持たせる。第一部にはRFC、IANA識別子、プロトコル版、鍵交換族、MUST NOTまたはSHOULD NOTを記す。TLS 1.3で許容されるFFDHEを名前の類似だけで消したり、静的ECDHの例外意味を静的RSAと同一視したりしないためだ。

第二部は実効制御点を固定する。正本となる設定源、承認リビジョン、生成済みポリシー、ソフトウェアや装置の版、アドレス、ポート、トランスポート、リスナー、SNI、上流プロキシ、実際の終端位置を記録する。分散終端では「全体ポリシー更新済み」という文だけでは分母にならない。

第三部は反映の証拠である。再起動、ホットリロード、管理配布の種別、時刻、変更番号、対象母数、成功・失敗・未到達、ロールバック版を残す。ファイル差分は意図を示す。プロセス識別子と読込済みポリシーは実行に近い証拠になる。

第四部は挙動を扱う。禁止方式だけを提示した負試験、代替方式を含めた選択試験、提示と選択のテレメトリー、観測期間、サンプリング欠損を記録する。「見えなかった」を「起こり得ない」へ言い換えない。

最後に例外と依存クライアントを結ぶ。用途、範囲、補償策、責任者、承認、失効日、出口条件、クライアント移行、互換経路の撤去を揃える。期限のない例外は移行措置ではなく、第二の恒久ポリシーである。

これはDaniel Kadeによるガバナンス上の提案であり、RFC 10015が要求する新しいプロトコル成果物ではない。目的は、機械が規範の変更を高速に読めるからといって、機械が未確認の稼働状態まで作り出すことを防ぐことにある。

証明できる言葉だけを使う

自動化の判定は「レジストリで非推奨」「設定から削除」「再読込確認」「禁止提示を拒否」「明示した範囲で選択観測なし」「例外終了」のように層を示すべきだ。すべての関連終端経路が閉じて初めて「無効化済み」と言える。

この語彙は障害対応にも効く。禁止された選択が再発したとき、正本、生成、配布、終端点台帳、例外、依存クライアントのどこで破れたかを追える。単一のコンプライアンス値では因果関係が消える。

標準化は出発線を明確にした。そこから先の問いは運用統治に属する。古い選択をまだ実行できるのはどのプロセスか。その可能性が閉じたと誰が、どの証拠で言えるのか。

情報源