Internet Engineering Task Force (IETF) R. Salz
Request for Comments: 9852 Akamai Technologies
BCP: 195 N. Aviram
Updates: 9325 July 2026
Category: Best Current Practice
ISSN: 2070-1721
TLS 1.3 is widely used, has had comprehensive security proofs, and improves both security and privacy deficiencies in TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.
TLS 1.3 は広く使用されており、包括的なセキュリティ証明があり、TLS 1.2 のセキュリティとプライバシーの両方の欠陥が改善されています。したがって、TLS を使用する新しいプロトコルには TLS 1.3 が必要です。DTLS 1.3 は広く利用または展開されていないため、この規定は DTLS (どの DTLS バージョンでも) には関係しません。これは TLS のみに関係します。
This document updates RFC 9325. It discusses post-quantum cryptography and the security and privacy improvements in TLS 1.3 as the rationale for the update.
この文書は RFC 9325 を更新します。この文書では、更新の理論的根拠として、量子後暗号化と、TLS 1.3 のセキュリティとプライバシーの改善について説明します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベスト プラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。BCP の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9852.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9852 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions
3. Implications for Post-Quantum Cryptography (PQC)
4. TLS Use by Other Protocols and Applications
5. Changes to RFC 9325
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Authors' Addresses
This document specifies that new protocols that use TLS must assume that TLS 1.3 is available and require its use. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.
この文書では、TLS を使用する新しいプロトコルは TLS 1.3 が利用可能であることを前提とし、その使用を必要とすることを指定しています。DTLS 1.3 は広く利用または展開されていないため、この規定は DTLS (どの DTLS バージョンでも) には関係しません。これは TLS のみに関係します。
TLS 1.3 [TLS13] is in widespread use and fixes most known deficiencies with TLS 1.2. Examples of this include encrypting more of the traffic so that it is not readable by outsiders and removing most cryptographic primitives now considered weak. Importantly, the protocol has had comprehensive security proofs and should provide excellent security without any additional configuration.
TLS 1.3 [TLS13] は広く使用されており、TLS 1.2 の既知の欠陥のほとんどが修正されています。この例には、部外者が読み取れないようにトラフィックをより多く暗号化することや、現在脆弱であると考えられているほとんどの暗号化プリミティブを削除することが含まれます。重要なのは、このプロトコルには包括的なセキュリティ証明があり、追加の構成を行わなくても優れたセキュリティを提供できるはずです。
TLS 1.2 [TLS12] is in use and can be configured such that it provides good security properties. However, TLS 1.2 suffers from several deficiencies, as described in Section 6. Addressing them usually requires bespoke configuration.
TLS 1.2 [TLS12] が使用されており、優れたセキュリティ特性を提供するように構成できます。ただし、セクション 6 で説明するように、TLS 1.2 にはいくつかの欠陥があります。通常、これらに対処するには、特注の構成が必要です。
This document updates [RFC9325]. It discusses post-quantum cryptography and the security and privacy improvements in TLS 1.3 as the rationale for the update. See Section 5.
この文書は [RFC9325] を更新します。アップデートの根拠として、ポスト量子暗号と、TLS 1.3 のセキュリティとプライバシーの向上について説明します。セクション 5 を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Cryptographically Relevant Quantum Computers (CRQCs), once available, will have a huge impact on TLS traffic (see, e.g., Section 3 of [RFC9958]). To mitigate this, TLS applications will need to migrate to Post-Quantum Cryptography (PQC) [PQC]. Detailed considerations of when an application requires PQC or when a CRQC is a threat that an application needs to protect against are beyond the scope of this document.
暗号関連量子コンピュータ (CRQC) が利用可能になれば、TLS トラフィックに大きな影響を与えるでしょう (例えば、[RFC9958] のセクション 3 を参照)。これを軽減するには、TLS アプリケーションをポスト量子暗号 (PQC) [PQC] に移行する必要があります。アプリケーションで PQC が必要な場合、または CRQC がアプリケーションを保護する必要がある脅威である場合の詳細な考慮事項は、このドキュメントの範囲を超えています。
It is important to note that the TLS Working Group is focusing its efforts on TLS 1.3 or later; TLS 1.2 will not be supported (see [TLS12FROZEN]). This is one more reason for new protocols to require TLS to default to TLS 1.3, where PQC is actively being standardized, as this gives new applications the option to use PQC.
TLS ワーキング グループは TLS 1.3 以降に重点を置いていることに注意することが重要です。TLS 1.2 はサポートされません ([TLS12FROZEN] を参照)。これは、新しいプロトコルが TLS のデフォルトを TLS 1.3 にすることを要求するもう 1 つの理由です。これにより、新しいアプリケーションに PQC を使用するオプションが与えられるため、PQC が積極的に標準化されています。
Any new protocol that uses TLS MUST specify TLS 1.3 as its default. For example, QUIC [QUICTLS] requires TLS 1.3 and specifies that endpoints MUST terminate the connection if an older version is used.
TLS を使用する新しいプロトコルは、デフォルトとして TLS 1.3 を指定しなければなりません。たとえば、QUIC [QUICTLS] は TLS 1.3 を必要とし、古いバージョンが使用されている場合はエンドポイントが接続を終了しなければならないと指定しています。
If deployment considerations are a concern, the protocol MAY specify TLS 1.2 as an additional, non-default option. As a counter example, the Usage Profile for DNS over TLS [DNSTLS] specifies TLS 1.2 as the default, while also allowing TLS 1.3. For newer specifications that choose to support TLS 1.2, those preferences are to be reversed.
展開に関する考慮事項が懸念される場合、プロトコルは追加のデフォルト以外のオプションとして TLS 1.2 を指定してもよい(MAY)。反例として、DNS over TLS [DNSTLS] の使用プロファイルでは、TLS 1.2 をデフォルトとして指定していますが、TLS 1.3 も許可しています。TLS 1.2 のサポートを選択した新しい仕様の場合、これらの設定は元に戻されます。
The initial TLS handshake allows a client to specify which versions of TLS it supports, and the server is intended to pick the highest version that it also supports. This is known as "TLS version negotiation"; protocol and negotiation details are discussed in Section 4.2.1 of [TLS13] and Appendix E of [TLS12]. Many TLS libraries provide a way for applications to specify the range of versions they want, including an open interval where only the lowest or highest version is specified.
最初の TLS ハンドシェイクにより、クライアントはサポートする TLS のバージョンを指定でき、サーバーは、同様にサポートする最高のバージョンを選択することを目的としています。これは「TLS バージョン ネゴシエーション」として知られています。プロトコルとネゴシエーションの詳細は、[TLS13] のセクション 4.2.1 および [TLS12] の付録 E で説明されています。多くの TLS ライブラリは、アプリケーションが必要なバージョンの範囲を指定する方法を提供します。これには、最低または最高のバージョンのみを指定するオープン インターバルも含まれます。
If the application is using a TLS implementation that supports TLS version negotiation and if it knows that the TLS implementation will use the highest version supported, then clients SHOULD specify just the minimum version they want. This MUST be TLS 1.3 or TLS 1.2, depending on the circumstances described in the above paragraphs.
アプリケーションが TLS バージョン ネゴシエーションをサポートする TLS 実装を使用しており、その TLS 実装がサポートされている最も高いバージョンを使用することがわかっている場合、クライアントは必要な最小バージョンのみを指定する必要があります (SHOULD)。これは、上記の段落で説明した状況に応じて、TLS 1.3 または TLS 1.2 でなければなりません。
[RFC9325] provides recommendations for ensuring the security of deployed services that use TLS and, unlike this document, DTLS as well. [RFC9325] describes TLS 1.3 as "widely available", and the transition to TLS 1.3 has further increased since publication of that document. This document thus makes two changes to the recommendations in Section 3.1.1 of [RFC9325]:
[RFC9325] は、TLS を使用する展開されたサービスのセキュリティを確保するための推奨事項を提供します。また、この文書とは異なり、DTLS も使用します。[RFC9325] では TLS 1.3 が「広く利用可能」であると説明されており、その文書の公開以来、TLS 1.3 への移行はさらに進んでいます。したがって、この文書は、[RFC9325] のセクション 3.1.1 の推奨事項に 2 つの変更を加えます。
* That section says that TLS 1.3 SHOULD be supported; this document mandates that TLS 1.3 MUST be supported for new protocols using TLS.
* このセクションには、TLS 1.3 がサポートされるべきであると記載されています。この文書は、TLS を使用する新しいプロトコルに対して TLS 1.3 をサポートしなければならないことを義務付けています。
* That section says that TLS 1.2 MUST be supported; this document says that TLS 1.2 MAY be supported as described above.
* このセクションには、TLS 1.2 がサポートされなければならないと記載されています。この文書には、上記のように TLS 1.2 がサポートされてもよいと記載されています。
Again, these changes only apply to TLS, and not DTLS.
繰り返しますが、これらの変更は TLS にのみ適用され、DTLS には適用されません。
TLS 1.2 was specified with several cryptographic primitives and design choices that have, over time, become significantly weaker. The purpose of this section is to briefly survey several such prominent problems that have affected the protocol. It should be noted, however, that TLS 1.2 can be configured securely; it is merely much more difficult to configure it securely as opposed to using its modern successor, TLS 1.3. See [RFC9325] for a more thorough guide on the secure deployment of TLS 1.2.
TLS 1.2 は、いくつかの暗号化プリミティブと設計上の選択肢を使用して仕様化されましたが、時間の経過とともに、それらは大幅に弱くなってきました。このセクションの目的は、プロトコルに影響を与えたいくつかの顕著な問題を簡単に調査することです。ただし、TLS 1.2 は安全に構成できることに注意してください。最新の後継である TLS 1.3 を使用するのと比べて、安全に構成することがはるかに難しいだけです。TLS 1.2 の安全な展開に関するより完全なガイドについては、[RFC9325] を参照してください。
First, without any extensions, TLS 1.2 is vulnerable to renegotiation attacks (see [RENEG1] and [RENEG2]) and the Triple Handshake attack (see [TRIPLESHAKE]). Broadly, these attacks exploit the protocol's support for renegotiation in order to inject a prefix chosen by the attacker into the plaintext stream. This is usually a devastating threat in practice (e.g., it allows an attacker to obtain secret cookies in a web setting). In light of the above problems, [RFC5746] specifies an extension that prevents this category of attacks. To securely deploy TLS 1.2, either renegotiation must be disabled entirely, or this extension must be used. Additionally, clients must not allow servers to renegotiate the certificate during a connection.
まず、拡張機能がなければ、TLS 1.2 は再ネゴシエーション攻撃 ([RENEG1] および [RENEG2] を参照) およびトリプル ハンドシェイク攻撃 ([TRIPLESHAKE] を参照) に対して脆弱です。概して、これらの攻撃は、攻撃者が選択したプレフィックスを平文ストリームに挿入するために、プロトコルの再ネゴシエーションのサポートを悪用します。これは通常、実際には壊滅的な脅威です (たとえば、攻撃者が Web 設定で秘密の Cookie を取得できるようになります)。上記の問題を考慮して、[RFC5746] はこのカテゴリの攻撃を防ぐ拡張機能を指定しています。TLS 1.2 を安全に展開するには、再ネゴシエーションを完全に無効にするか、この拡張機能を使用する必要があります。さらに、クライアントは、接続中にサーバーが証明書を再ネゴシエートすることを許可してはなりません。
Second, the original key exchange methods specified for TLS 1.2, namely RSA key exchange and finite field Diffie-Hellman, suffer from several weaknesses. To securely deploy the protocol, most of these key exchange methods must be disabled. See [RFC10015] for details.
第 2 に、TLS 1.2 に指定されている元の鍵交換方式、つまり RSA 鍵交換と有限体 Diffie-Hellman には、いくつかの弱点があります。プロトコルを安全に展開するには、これらのキー交換メソッドのほとんどを無効にする必要があります。詳細については[RFC10015]を参照してください。
Third, symmetric ciphers that are widely used in TLS 1.2, namely RC4 and Cipher Block Chaining (CBC) cipher suites, suffer from several weaknesses. RC4 suffers from exploitable biases in its key stream; see [RFC7465]. CBC cipher suites have been a source of vulnerabilities throughout the years. A straightforward implementation of these cipher suites inherently suffers from the Lucky13 timing attack [LUCKY13]. The first attempt to implement the cipher suites in constant time introduced an even more severe vulnerability [LUCKY13FIX]. Refer to [CBCSCANNING] for another example of a vulnerability with CBC cipher suites and a survey of similar works.
3 番目に、TLS 1.2 で広く使用されている対称暗号、つまり RC4 および Cipher Block Chaining (CBC) 暗号スイートには、いくつかの弱点があります。RC4 は、その主要なストリームに悪用可能なバイアスに悩まされています。[RFC7465]を参照してください。CBC 暗号スイートは長年にわたって脆弱性の原因となってきました。これらの暗号スイートの単純な実装は、本質的に Lucky13 タイミング攻撃 [LUCKY13] の影響を受けます。一定時間内に暗号スイートを実装する最初の試みでは、さらに深刻な脆弱性 [LUCKY13FIX] が導入されました。CBC 暗号スイートの脆弱性の別の例と同様の作業の調査については、[CBCSCANNING] を参照してください。
In addition, TLS 1.2 was affected by several other attacks that TLS 1.3 is immune to: BEAST [BEAST], Logjam [WEAKDH], FREAK [FREAK], and SLOTH [SLOTH].
さらに、TLS 1.2 は、TLS 1.3 が影響を受けない他のいくつかの攻撃 (BEAST [BEAST]、Logjam [WEAKDH]、FREAK [FREAK]、および SLOTH [SLOTH]) の影響を受けました。
Finally, while application-layer traffic in TLS 1.2 is always encrypted, most of the content of the handshake messages is not. Therefore, the privacy provided is suboptimal. This is a protocol issue that cannot be addressed by configuration.
最後に、TLS 1.2 のアプリケーション層トラフィックは常に暗号化されますが、ハンドシェイク メッセージのコンテンツのほとんどは暗号化されません。したがって、提供されるプライバシーは最適とは言えません。これは、設定では対処できないプロトコルの問題です。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[TLS12FROZEN]
Salz, R. and N. Aviram, "TLS 1.2 is in Feature Freeze",
RFC 9851, DOI 10.17487/RFC9851, July 2026,
<https://www.rfc-editor.org/info/rfc9851>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[BEAST] Duong, T. and J. Rizzo, "Here Come the XOR Ninjas", May
2011, <http://www.hpcc.ecs.soton.ac.uk/dan/talks/bullrun/
Beast.pdf>.
[CBCSCANNING]
Merget, R., Somorovsky, J., Aviram, N., Young, C.,
Fliegenschmidt, J., Schwenk, J., and Y. Shavitt, "Scalable
Scanning and Automatic Classification of TLS Padding
Oracle Vulnerabilities", 28th USENIX Security Symposium
(USENIX Security 19), August 2019,
<https://www.usenix.org/system/files/sec19-merget.pdf>.
[DNSTLS] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[FREAK] Beurdouche, B., Bhargavan, K., Delignat-Lavaud, A.,
Fournet, C., Kohlweiss, M., Pironti, A., Strub, P.-Y., and
J. K. Zinzindohoue, "A Messy State of the Union: Taming
the Composite State Machines of TLS", IEEE Symposium on
Security & Privacy 2015, HAL ID: hal-01114250, May 2015,
<https://inria.hal.science/hal-01114250/file/messy-state-
of-the-union-oakland15.pdf>.
[LUCKY13] Al Fardan, N. J. and K. G. Paterson, "Lucky Thirteen:
Breaking the TLS and DTLS record protocols", February
2013, <http://www.isg.rhul.ac.uk/tls/TLStiming.pdf>.
[LUCKY13FIX]
Somorovsky, J., "Systematic Fuzzing and Testing of TLS
Libraries", CCS '16: Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, pp.
1492-1504, DOI 10.1145/2976749.2978411, October 2016,
<https://nds.rub.de/media/nds/
veroeffentlichungen/2016/10/19/tls-attacker-ccs16.pdf>.
[PQC] NIST, "What Is Post-Quantum Cryptography?", June 2025,
<https://www.nist.gov/cybersecurity/what-post-quantum-
cryptography>.
[QUICTLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RENEG1] Rescorla, E., "Understanding the TLS Renegotiation
Attack", Wayback Machine archive, 5 November 2009,
<https://web.archive.org/web/20091231034700/
http://www.educatedguesswork.org/2009/11/
understanding_the_tls_renegoti.html>.
[RENEG2] Ray, M., "Authentication Gap in TLS Renegotiation",
Wayback Machine archive,
<https://web.archive.org/web/20091228061844/
http://extendedsubset.com/?p=8>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<https://www.rfc-editor.org/info/rfc5746>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>.
[RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
<https://www.rfc-editor.org/info/rfc9958>.
[RFC10015] Aviram, N., "Deprecating Obsolete Key Exchange Methods in
TLS 1.2 and DTLS 1.2", RFC 10015, DOI 10.17487/RFC10015,
July 2026, <https://www.rfc-editor.org/info/rfc10015>.
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH",
Network and Distributed System Security Symposium - NDSS
2016, DOI 10.14722/ndss.2016.23418, HAL ID: hal-01244855,
February 2016, <https://inria.hal.science/hal-
01244855/file/SLOTH_NDSS16.pdf>.
[TRIPLESHAKE]
"Triple Handshakes Considered Harmful: Breaking and Fixing
Authentication over TLS", Wayback Machine archive,
<https://web.archive.org/web/20250804151857/
https://mitls.org/pages/attacks/3SHAKE>.
[WEAKDH] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
Green, M., Halderman, J. A., Heninger, N., Springall, D.,
Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Zanella-Beguelin, S., and P. Zimmerman, "Imperfect Forward
Secrecy: How Diffie-Hellman Fails in Practice", CCS '15:
Proceedings of the 22nd ACM SIGSAC Conference on Computer
and Communications Security, pp. 5-17,
DOI 10.1145/2810103.2813707, October 2015,
<https://dl.acm.org/doi/pdf/10.1145/2810103.2813707>.
Rich Salz
Akamai Technologies
Email: rsalz@akamai.com
Nimrod Aviram
Email: nimrod.aviram@gmail.com