要約

  • RFC 9851 が凍結するのは TLS 1.2 の新しい標準機能である。TLS Working Group の合意による緊急セキュリティ修正、ALPN Protocol ID、TLS Exporter Label は例外で、レジストリ自体は閉じない。
  • 同RFCは、どの版の DTLS にも適用しない。ましてやサーバー設定、実際のネゴシエーション、顧客依存、移行完了を証明する文書ではない。

資産台帳の更新後、TLS 1.2 と DTLS 1.2 の全行に同じ「機能凍結」タグが付いた。担当者は名称を短くしただけだと考えた。しかし次の調達審査では、そのタグが「新規仕様は禁止」「製品は廃止済み」「例外不要」という三つの判断に使われた。

省略された一文字の D が、決定の対象を変えていた。

これは実在する組織やシステムの報告ではない。境界は2026年7月にIETF Proposed Standardとして公開された RFC 9851 にある。題名は TLS 1.2 is in Feature Freeze。TLS 1.2について、TLS Working Groupの合意が緊急セキュリティ修正と認める場合、および第4節の例外を除き、新たな変更を承認しないと定める。

ここで止められるのは標準化の流れである。RFCはロードバランサーの最小バージョンを変更せず、ライブラリを更新せず、パートナー端末を列挙せず、ClientHelloやServerHelloを観測しない。RFC 5246 はTLS 1.2の保存された仕様として残り、既存実装も所有者が変えるまで動き続け得る。

緊急修正にも主体がある。現場の障害票に「緊急」と書くことと、TLS Working Groupが合意によって例外を認めることは同じではない。将来、標準上の修正が承認されても、その事実は各製品への実装、配布、設定、実行を証明しない。承認記録と稼働記録は別に保存すべきだ。

第4節はTLSレジストリを一つも閉鎖しない。IANAとDesignated Expertsへの指示を変え、承認後に追加される多くの項目をTLS 1.3以降向けとし、Comment欄などにその旨を示すよう求める。IANA Transport Layer Security Parameters は割当と方針の台帳であり、端点の設定画面ではない。

制限を追加されないレジストリが二つある。Application-Layer Protocol Negotiation Protocol IDsとTLS Exporter Labelsである。ALPNは上位プロトコルの識別を、Exporter Labelはエクスポート鍵素材の用途分離を支える。どちらもTLS 1.2に新しい暗号方式やハンドシェイク機能を足さずに、世代をまたいで使える名前空間である。

したがって、新しいALPN IDの登録を「TLS 1.2の新機能」と数えるのは誤りだ。登録は名前と参照仕様を証明するが、サーバーが提供したこと、クライアントが選んだこと、アプリケーションが動いたことを証明しない。Exporter Labelも、登録された値と、実際に正しい文脈で鍵素材が導出・利用された事実を分けなければならない。

RFC 9847 は、TLS/DTLSレジストリの Y、N、D を整理する。Dは利用が問題を生み得るため非推奨であり、根拠をReferenceまたはCommentから追える必要がある。分類は重要な共通判断だが、対象装置の有効設定を読み取った結果ではない。

そしてRFC 9851は明示的に「TLSだけ」と書く。どのDTLS版にも適用しない。RFC 9325 がTLSとDTLS双方の安全な利用を扱うからこそ、後続文書ごとの適用範囲を確認する必要がある。似た名前は同じ決定対象を保証しない。

RFC 10015 は隣接する別の規則である。TLS 1.2とDTLS 1.2の特定の古い鍵交換方式を廃止・抑制する。その方式別要件と端点検証は既存記事の領域だ。RFC 9851からDTLS凍結を導く根拠にはならず、TLS 1.2全体の停止証明にもならない。

PQCについては将来の向きが明確である。RFC 9851は、TLS Working Groupの作業をTLS 1.3以降に集中させ、TLS 1.2向けPQCは標準化しないと述べる。RFC 9958 はエンジニア向けの移行背景を示し、RFC 9846 はTLS 1.3の現行仕様を示す。

ただしTLS 1.3対応という一行からPQC対応を推測してはならない。ハイブリッド方式の仕様、ライブラリ実装、有効設定、選択されたグループ、相手認証、アプリケーション受理は別の層にある。TLS 1.2に将来のPQC仕様がないことも、特定の通信が既に破られた証拠ではない。

RFC 9852 は新しいTLS利用プロトコルにTLS 1.3を既定として要求し、導入事情がある場合にTLS 1.2を追加の非既定選択肢として許す。「新しいプロトコル」という条件が重要だ。設計時の既定値は、既存サービスの変更実績にはならない。

Heng LuのMinimum Initial Specification に従えば、共通層は将来の標準化先、例外の種類、緊急修正の決定者だけを明確にする。個々の端点、顧客、期限を決めるのはローカルな所有者である。共通層を大きく語るほど、所有者が消える。

Reality Layers を使えば、RFC公開、IANA行、コンパイル済み能力、ロード済み設定、クライアントの提示、サーバーの選択、アプリケーションの成功は別の現実層になる。文書上の一致を、実行結果へ自動昇格させてはならない。

Running-Code Primacy は問いに応じた証拠順位を与える。「TLS 1.2の新機能は今後承認されるか」にはRFCが答える。「この入口はTLS 1.2を選んだか」には実行コード、設定、通信観測が答える。二つを競わせる必要はなく、担当する問いを分ければよい。

運用台帳は製品単位より終端単位で作るべきだ。CDN、リバースプロキシ、APIゲートウェイ、サービスメッシュ、メール中継、組込み装置は、同じサービス名の下で別々にTLSを終端し得る。リスナー、アドレス系、ライブラリとビルド、許可バージョン、暗号・グループ方針、ALPN、証明書、クライアント群、例外所有者と期限を紐付ける。

一回のTLS 1.3カナリア成功は、その経路と時刻の成功でしかない。予備リスナー、IPv6、低頻度パートナー、災害時経路にTLS 1.2が残っていないとは言えない。ゼロ観測も、収集範囲と観測期間、欠測を説明して初めて否定証拠になる。

廃止完了の受領証には、権威ある設定、資産照合、十分な期間の観測、代表的な能動試験、依存所有者の確認、旧クライアントの意図した拒否、ロールバック状態が必要だ。単一の緑色チェックでは、それぞれの問いに答えられない。

RFC Editor情報ページ は公開日、区分、著者、Working Groupを確定する。Errata検索 は報告された訂正の確認面である。どちらも現行製品の採用や交渉結果を観測していない。

機能凍結は軽いニュースではない。待てばTLS 1.2に新機能やPQCが戻ってくるという期待を閉じ、将来プロトコルの投資をTLS 1.3以降へ向ける。しかし標準化の時間を止める決定と、機械の上で最後の旧接続を止める作業は、別の所有者と別の証拠を持つ。

出典