RFC 10015: TLS 1.2 および DTLS 1.2 における古い鍵交換方式の非推奨化

RFC 10015 古い鍵交換方式の非推奨化 (D 2026年7月 Aviram Standards Track [Page] Stream: Internet Engineering Task Force (IETF) RFC: 10015 更新: 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, 9325 カテゴリ: Standards Track 発行日: 2026年7月 ISSN: 2070-1721 著者: N. Aviram RFC 10015 TLS 1.2 および DTLS 1.2 における古い鍵交換方式の非推奨化 概要 (D)TLS 1.2 に関して、本ドキュメントは2つの鍵交換方式、すなわち有限体上の Diffie-Hellman (DH) および RSA の使用を非推奨とします。また、静的な楕円曲線 Diffie-Hellman (ECDH) 暗号スイートの使用も推奨しないとしています。 これらの規定は (D)TLS 1.2 にのみ適用されます。なぜなら、(D)TLS 1.0 および TLS 1.1 は RFC 8996 によって非推奨とされており、(D)TLS 1.3 は影響を受けるアルゴリズムを使用しないか、関連する設定オプションを共有しないからです。（DTLSにはバージョン1.1は存在しません。） 本ドキュメントは、RFC 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, および 9325 を更新し、(D)TLS 1.2 接続において上記の鍵交換方式を使用する暗号スイートの使用を非推奨または推奨しないものとします。 本文書のステータス これは Internet Standards Track ドキュメントです。 本文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティのコンセンサスを表しています。公開レビューを受けており、Internet Engineering Steering Group (IESG) によって発行が承認されています。Internet Standards に関する追加情報は、RFC 7841 のセクション2で入手可能です。 本文書の現在のステータス、誤り、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10015 で入手できます。 著作権表示 Copyright (c) 2026 IETF Trust およびドキュメントの著者が特定した個人。 全著作権所有。 本文書は、本文書の発行日時点で有効な BCP 78 および IETF Trust の法的条項 (https://trustee.ietf.org/license-info) の対象となります。これらのドキュメントは、本文書に関するお客様の権利と制限について説明しているため、注意深く確認してください。本文書から抽出されたコードコンポーネントには、Trust Legal Provisions のセクション 4.e に記載されている Revised BSD License テキストを含める必要があり、Revised BSD License に記載されているとおり、保証なしで提供されます。 目次 1. はじめに (D)TLS 1.2 は、RSA、有限体上の Diffie-Hellman (DH)、および楕円曲線 Diffie-Hellman (ECDH) を含む、さまざまな鍵交換アルゴリズムをサポートしています。 DH 鍵交換は、任意のグループにおいて、エフェメラル（一時的）と非エフェメラルのバリエーションがあります。非エフェメラル DH アルゴリズムは、認証されたピアの証明書に含まれる静的な DH 公開鍵を使用します（[RFC4492] で議論）。対照的に、エフェメラル DH アルゴリズムは、ハンドシェイク中に送信され、ピアの証明書によって認証されるエフェメラル DH 公開鍵を使用します。エフェメラルおよび非エフェメラルの有限体 DH アルゴリズムは、それぞれ DHE および DH（または FFDHE および FFDH）と呼ばれ、エフェメラルおよび非エフェメラルの楕円曲線 DH アルゴリズムは、それぞれ ECDHE および ECDH と呼ばれます [RFC4492]。 一般的に、非エフェメラル暗号スイートはフォワードシークレット（前方秘匿性）がないため推奨されません。さらに、有限体 DH に対する Raccoon 攻撃 [RACCOON] で実証されているように、公開鍵の再利用（非エフェメラル暗号スイートを介した、またはエフェメラル暗号スイートで再利用された鍵）は、接続秘密を漏洩する可能性のあるタイミングサイドチャネルにつながる可能性があります。ECDH に関しては、無効な曲線攻撃も同様に秘密の再利用を悪用してセキュリティを破る [ICA] ことができ、公開鍵の再利用のリスクをさらに示しています。これらのサイドチャネルは実装で回避できますが、経験上、必要な緩和策の複雑さと数の多さから、実装がこれらの攻撃を阻止できない場合があります。 さらに、RSA 鍵交換は、実装の選択とは独立したセキュリティ上の問題に加え、セキュリティ対策を正しく実装することの難しさから生じる問題も抱えています。 FFDHE が (D)TLS 1.2 で抱える問題は、大まかに言うと以下の通りです。 FFDHE は、グループをネゴシエートするメカニズムがなく、一部の実装が小さなグループサイズしかサポートしないため、相互運用性の問題に悩まされています（[RFC7919]、セクション1を参照）。 FFDHE グループには小さなサブグループが存在する可能性があり、これがいくつかの攻撃を可能にします [SUBGROUPS]。カスタムで非標準的な FFDHE グループが提示された場合、ハンドシェイク中のクライアントは、選択されたグループがこの問題の影響を受けないことを実質的に検証できません。また、このようなハンドシェイクがクライアントが受け入れ可能な他の鍵交換パラメータにフォールバックするメカニズムもありません。カスタム FFDHE グループは広く普及しています（[WEAK-DH] に基づくアドバイスの結果）。したがって、クライアントはカスタムで、したがって潜在的に危険なグループを提示するハンドシェイクを単純に拒否することはできません。 実際には、一部のオペレーターは 1024 ビット FFDHE グループを使用しています。これは、広範なサポートを保証する最大サイズであるためです（[RFC7919]、セクション1を参照）。このサイズでは、現在の離散対数記録（795 ビット [DLOG795]）に対してセキュリティマージンが小さくなります。 前のポイントを拡張すると、わずかな非常に大規模な計算で、攻撃者は比較的大きな割合の FFDHE トラフィック（特定の標準化されたグループを使用して暗号化されたトラフィック）を安価に復号できます [WEAK-DH]。 秘密が完全にエフェメラルでない場合、FFDHE は Raccoon サイドチャネル攻撃 [RACCOON] の影響を受けます。（FFDH は、定数時間緩和策が採用されない限り、本質的に Raccoon 攻撃に対して脆弱であることに注意してください。） RSA 鍵交換が (D)TLS 1.2 で抱える問題は以下の通りです。 RSA 鍵交換は、その設計上、フォワードシークレットを提供しません。 RSA 鍵交換は、Bleichenbacher の攻撃 [BLEI] に対して脆弱である可能性があります。経験上、関連する対策を正しく実装することが難しいため、この攻撃のバリアントが数年ごとに発生しています（[ROBOT]、[NEW-BLEI]、および [DROWN] を参照）。 上記の点に加えて、(D)TLS 1.2 には鍵のドメイン分離のための便利なメカニズムがありません。したがって、Bleichenbacher の攻撃に対して脆弱な単一のエンドポイントは、同じ RSA 鍵を共有するすべて のエンドポイントに影響を与える可能性があります（[XPROT] および [DROWN] を参照）。 本ドキュメントは、セクション 5.2、5.3、5.4、および 5.5 に記載されている影響を受ける暗号スイートを非推奨および推奨しないことにより、上記の問題を解決するために [RFC4162]、[RFC4279]、[RFC4346]、[RFC4785]、[RFC5246]、[RFC5288]、[RFC5289]、[RFC5469]、[RFC5487]、[RFC5932]、[RFC6209]、[RFC6347]、[RFC6367]、[RFC6655]、[RFC7905]、[RFC8422]、および [RFC9325] を更新します。 BCP 195 [RFC8996] [RFC9325] には、(D)TLS プロトコル（特に (D)TLS 1.2）のユーザーに対する最新の IETF 推奨事項が含まれており、本ドキュメントは [RFC9325] をいくつかの点で更新します。セクション6に正確な違いを詳述します。BCP ドキュメントの他のすべての推奨事項は有効なままです。 1.1. 要件言語 このドキュメントでは、「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」というキーワードは、それらがすべて大文字で表示される場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されているとおりに解釈されるものとします。 2. 非エフェメラル Diffie-Hellman クライアントは非エフェメラル FFDH 暗号スイートをオファーしてはならず、サーバーは (D)TLS 1.2 接続で非エフェメラル FFDH 暗号スイートを選択してはなりません。（(D)TLS 1.0 および TLS 1.1 は [RFC8996] によって非推奨とされており、(D)TLS 1.3 は FFDH をサポートしないことに注意してください [RFC9846] [RFC9147]。）これには、セクション 5.1 の表1に記載されているすべての暗号スイートが含まれます。 クライアントは非エフェメラル ECDH 暗号スイートをオファーしないものとし、サーバーは (D)TLS 1.2 接続で非エフェメラル ECDH 暗号スイートを選択しないものとします。（この要件は [RFC9325] に既に存在します。(D)TLS 1.0 および TLS 1.1 は [RFC8996] によって非推奨とされており、(D)TLS 1.3 は ECDH をサポートしないことに注意してください [RFC9846] [RFC9147]。）これには、セクション 5.2 の表2に記載されているすべての暗号スイートが含まれます。 さらに、非エフェメラル DH の使用を避けるため、クライアントは使用しないものとし、サーバーは SHOU