| RFC 9852 | TLSを使用する新しいプロトコルはTLSを必須としなければならない | 2026年7月 |
| Salz & Aviram | 現行の最良慣行 | [ページ] |
TLS 1.3は広く使用されており、包括的なセキュリティ証明がなされ、 TLS 1.2のセキュリティおよびプライバシー上の欠点を改善している。したがって、TLSを使用する新しいプロトコルは TLS 1.3を必須としなければならない。DTLS 1.3は広く利用可能でも 展開されてもいないため、この規定はDTLS（いずれのDTLSバージョンも）には適用されず、 TLSのみに適用される。¶
この文書はRFC 9325を更新する。この更新の根拠として、耐量子暗号、および TLS 1.3におけるセキュリティとプライバシーの改善について説明する。¶
このメモは、インターネットの現行の最良慣行を文書化するものである。¶
この文書は、Internet Engineering Task Force (IETF)の成果物である。これはIETFコミュニティの総意を表すものである。公開 レビューを受け、Internet Engineering Steering Group (IESG)により公開が承認されている。BCPに関する詳細情報は、 RFC 7841のセクション2で参照できる。¶
この文書の現在の状態、正誤情報、および フィードバックの提供方法に関する情報は、 https://www.rfc-editor.org/info/rfc9852で入手できる。¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
この文書は、TLSを使用する新しいプロトコルが TLS 1.3を利用可能であると想定し、その使用を必須としなければならないことを規定する。 DTLS 1.3は広く利用可能でも 展開されてもいないため、この規定はDTLS（いずれのDTLSバージョンも）には適用されず、 TLSのみに適用される。¶
TLS 1.3 [TLS13]は広く 使用されており、TLS 1.2における既知の欠点のほとんどを修正している。その例として、トラフィックのより多くの部分を暗号化して 外部の第三者が読み取れないようにすることや、現在では脆弱と見なされている暗号プリミティブの ほとんどを削除することが挙げられる。重要な点として、このプロトコルには包括的な セキュリティ証明があり、追加の設定を行わなくても優れたセキュリティを 提供するはずである。¶
TLS 1.2 [TLS12]は使用されており、 良好なセキュリティ特性を提供するように 設定できる。しかし、TLS 1.2には、セクション6で説明する いくつかの欠点がある。これらに対処するには、通常、 個別に調整された設定が必要となる。¶
この文書は[RFC9325]を更新する。 この更新の根拠として、耐量子暗号、 およびTLS 1.3におけるセキュリティとプライバシーの改善について説明する。セクション5を参照されたい。¶
この文書におけるキーワード「しなければならない」、「してはならない」、「必須」、「するものとする」、「しては ならない」、「すべきである」、「すべきではない」、「推奨」、「推奨されない」、 「してもよい」、および「任意」は、ここに示すように すべて大文字で記載されている場合に限り、 BCP 14 [RFC2119] [RFC8174]に 記述されているとおりに解釈されるものとする。¶
暗号学的に意味のある量子コンピューター（CRQC）が利用可能になると、 TLSトラフィックに甚大な影響を与える（たとえば、[RFC9958]のセクション3を参照）。これを軽減するには、TLSアプリケーションを 耐量子暗号（PQC）[PQC]へ移行する 必要がある。アプリケーションがいつPQCを必要とするか、またはCRQCが アプリケーションによる保護を必要とする脅威となるのはいつかについての詳細な考慮は、この 文書の範囲外である。¶
重要な点として、 TLSワーキンググループはTLS 1.3 以降に取り組みを集中しており、TLS 1.2はサポートされない（[TLS12FROZEN]を参照）。 これは、新しいプロトコルがTLSのデフォルトをTLS 1.3とすることを必須にすべき もう一つの理由である。 TLS 1.3ではPQCの標準化が積極的に進められているため、新しいアプリケーションに PQCを使用する選択肢が与えられる。¶
TLSを使用する新しいプロトコルは、TLS 1.3を デフォルトとして規定しなければならない。 たとえば、QUIC [QUICTLS]はTLS 1.3を必須とし、 古いバージョンが使用された場合、エンドポイントは 接続を終了しなければならないと規定している。¶
展開上の考慮事項が問題となる場合、プロトコルは 追加の非デフォルトオプションとしてTLS 1.2を 規定してもよい。 反例として、DNS over TLSの使用プロファイル[DNSTLS]は、 TLS 1.3も許可しつつ、TLS 1.2をデフォルトとして規定している。 TLS 1.2のサポートを選択する、より新しい仕様では、これらの優先順位を 逆にすることになる。¶
最初のTLSハンドシェイクでは、クライアントがサポートする TLSのバージョンを指定でき、サーバーは自身もサポートする 最も高いバージョンを選択することが意図されている。これは「TLSバージョン ネゴシエーション」と呼ばれる。プロトコルおよびネゴシエーションの詳細については、 [TLS13]のセクション4.2.1および [TLS12]の付録Eで説明されている。多くのTLSライブラリは、 最低または最高のバージョンのみを指定する 開区間を含め、アプリケーションが希望するバージョン範囲を指定する方法を提供している。¶
アプリケーションがTLSバージョンネゴシエーションをサポートするTLS実装を使用しており、 かつTLS実装がサポートされる最も高いバージョンを使用することが 分かっている場合、 クライアントは希望する最低バージョンのみを指定すべきである。 上記の段落で説明した状況に応じて、これはTLS 1.3またはTLS 1.2で なければならない。¶
[RFC9325]は、TLS、およびこの文書とは異なり DTLSも使用する、展開済みサービスのセキュリティを確保するための 推奨事項を示している。 [RFC9325]はTLS 1.3を 「広く利用可能」と説明しており、その文書の公開以降、TLS 1.3への移行はさらに進んでいる。 したがって、この文書は、 [RFC9325]のセクション3.1.1にある推奨事項に 次の2つの変更を加える。¶
同セクションではTLS 1.3をサポートすべきであるとしているが、 この文書では、TLSを使用する新しいプロトコルについて TLS 1.3をサポートしなければならないと義務付ける。¶
同セクションではTLS 1.2をサポートしなければならないとしているが、 この文書では、上記のとおり TLS 1.2をサポートしてもよいとしている。¶
繰り返しになるが、これらの変更はTLSのみに適用され、DTLSには適用されない。¶
TLS 1.2は、時間の経過とともに著しく脆弱になった 複数の暗号プリミティブおよび設計上の選択を伴って規定された。このセクションの目的は、 プロトコルに影響を与えてきた、そのような顕著な問題のいくつかを 簡潔に概観することである。ただし、TLS 1.2は安全に設定できることに 注意すべきである。現代的な後継であるTLS 1.3を使用する場合と比べて、 安全に設定することがはるかに難しいにすぎない。TLS 1.2を 安全に展開するためのより詳細なガイドについては、[RFC9325]を参照されたい。¶
第一に、拡張機能を使用しないTLS 1.2は、 再ネゴシエーション攻撃（[RENEG1]および[RENEG2]を参照）と、 Triple Handshake攻撃（[TRIPLESHAKE]を参照）に対して脆弱である。 大まかに言えば、これらの攻撃は、攻撃者が選択したプレフィックスを 平文ストリームへ挿入するために、プロトコルによる再ネゴシエーションのサポートを悪用する。これは通常、 実際上、壊滅的な脅威となる（たとえば、Web環境では攻撃者が秘密のCookieを取得できる）。 上記の 問題を踏まえ、[RFC5746]は、この 種類の攻撃を防止する拡張機能を規定している。TLS 1.2を安全に展開するには、再ネゴシエーションを 完全に無効化するか、この拡張機能を使用しなければならない。さらに、クライアントは、 接続中にサーバーが証明書を再ネゴシエーションすることを許可してはならない。¶
第二に、TLS 1.2に対して当初規定されていた鍵交換方式、すなわち RSA鍵交換および有限体Diffie-Hellmanには、いくつかの 弱点がある。プロトコルを安全に展開するには、 これらの鍵交換 方式のほとんどを無効化しなければならない。 詳細については[RFC10015]を参照されたい。¶
第三に、TLS 1.2で広く使用されている共通鍵暗号、すなわちRC4 および暗号ブロック連鎖（CBC）暗号スイートには、いくつかの弱点がある。RC4には、 悪用可能なキーストリームの偏りがある。[RFC7465]を参照されたい。CBC暗号スイートは、 長年にわたり脆弱性の原因となってきた。これらの暗号スイートを単純に 実装すると、本質的にLucky13タイミング 攻撃[LUCKY13]の影響を受ける。暗号スイートを 定数時間で実装する最初の試みでは、さらに深刻な脆弱性[LUCKY13FIX]が生じた。 CBC暗号スイートに関する別の脆弱性の例、および類似研究の概観については、 [CBCSCANNING]を参照されたい。¶
さらに、TLS 1.2は、TLS 1.3には影響しない 他のいくつかの攻撃の影響も受ける。 BEAST [BEAST]、Logjam [WEAKDH]、FREAK [FREAK]、およびSLOTH [SLOTH]である。¶
最後に、 TLS 1.2のアプリケーション層トラフィックは常に暗号化されるが、ハンドシェイク メッセージの内容の大部分は暗号化されない。したがって、提供されるプライバシーは最適ではない。 これは、設定では対処できないプロトコル上の問題である。¶
この文書が必要とするIANAの処置はない。¶