RFC 9852

New Protocols Using TLS Must Require TLS 1.3

📅 published July 2026, from ietf

RFC 9852: New Protocols Using TLS Must Require TLS 1.3 🎀

Okay bestie, here's the vibe check on RFC 9852 🦋

  • Request for Comments: 9852
  • Organization: Internet Engineering Task Force (IETF)
  • Authors: R. Salz and N. Aviram, both at Akamai Technologies
  • Category: Best Current Practice, which makes it BCP 195 🫶
  • Date: July 2026
  • Updates: RFC 9325 ✨
  • Obsoletes: nothing listed in the title block
  • ISSN: 2070-1721

It's literally a best practice doc that's here to glow up how new protocols use TLS. Let's get into it 💅

Abstract ✨

TLS 1.3 is widely used, it has had comprehensive security proofs, and it improves on both the security and privacy problems in TLS 1.2. So new protocols that use TLS must require TLS 1.3 💖 DTLS 1.3 isn't widely available or deployed yet, so this doesn't apply to DTLS (in any DTLS version). It's TLS only, bestie.

This document updates RFC 9325. It talks about post-quantum cryptography and the security and privacy upgrades in TLS 1.3 as the reason for the update 🔮

Status of This Memo 📜

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.

Info about the current status of this document, any errata, and how to send feedback on it lives at 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.

Table of Contents 🗂️

   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

1. Introduction 🌸

Okay so the big idea is this: if you're making a brand-new protocol that runs over TLS, you need to assume TLS 1.3 is available, and you need to require it. DTLS 1.3 isn't widely available or deployed, so none of this applies to DTLS (in any DTLS version). TLS only, no cap 🧚

TLS 1.3 [TLS13] is in widespread use, and it fixes most of the known problems in TLS 1.2. Some examples: it encrypts more of the traffic so outsiders can't read it, and it drops most of the cryptographic primitives that are now considered weak. The best part is that the protocol has had comprehensive security proofs, and it should give you excellent security without any extra configuration 😭✨

TLS 1.2 [TLS12] is still in use, and it can be configured to have good security properties. However, TLS 1.2 has several deficiencies, which are described in Section 6. Fixing them usually takes bespoke configuration, and that's a whole mood 🙈

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 🦋

2. Conventions 📝

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. Basically, the capitals are the official signal, so watch for them 👀

3. Implications for Post-Quantum Cryptography (PQC) 🔮

Cryptographically Relevant Quantum Computers (CRQCs), once they're available, will have a huge impact on TLS traffic (see, e.g., Section 3 of [RFC9958]). To handle that, TLS applications will need to migrate to Post-Quantum Cryptography (PQC) [PQC]. Detailed considerations about when an application actually needs PQC, or when a CRQC is a threat an application needs to guard against, are beyond the scope of this document 💅

It's important to note that the TLS Working Group is focusing its efforts on TLS 1.3 or later, and TLS 1.2 will not be supported (see [TLS12FROZEN]). That's one more reason for new protocols to require TLS to default to TLS 1.3, where PQC is actively being standardized, since it gives new applications the option to use PQC 🌈

4. TLS Use by Other Protocols and Applications 🧚

Any new protocol that uses TLS MUST specify TLS 1.3 as its default. For example, QUIC [QUICTLS] requires TLS 1.3, and it specifies that endpoints MUST terminate the connection if an older version is used 💖

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 🔄

The initial TLS handshake lets a client say 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". The protocol and negotiation details are discussed in Section 4.2.1 of [TLS13] and Appendix E of [TLS12]. Lots of TLS libraries let applications specify the range of versions they want, including an open interval where only the lowest or highest version is specified 🫶

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 🎀

5. Changes to RFC 9325 🔄

[RFC9325] provides recommendations for keeping deployed services that use TLS secure, and unlike this document, it covers DTLS as well. It describes TLS 1.3 as "widely available", and the move to TLS 1.3 has only grown since that document was published. This document makes two changes to the recommendations in Section 3.1.1 of [RFC9325]:

  • 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.
  • That section says that TLS 1.2 MUST be supported. This document says that TLS 1.2 MAY be supported as described above.

Again, these changes only apply to TLS, and not DTLS 🦋

6. Security Considerations 🚨

Okay, this section is the serious one, so buckle up 😭 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 some of the most prominent problems that have affected the protocol. That said, TLS 1.2 can be configured securely. It's just much harder to configure it securely than to use its modern successor, TLS 1.3. See [RFC9325] for a more thorough guide to the secure deployment of TLS 1.2.

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 an attacker-chosen prefix into the plaintext stream. In practice this is usually a devastating threat. For example, it lets an attacker obtain secret cookies in a web setting 💀 In light of these problems, [RFC5746] specifies an extension that prevents this category of attacks. To deploy TLS 1.2 securely, 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.

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 deploy the protocol securely, most of these key exchange methods must be disabled. See [RFC10015] for details 🔥

Third, the symmetric ciphers that are widely used in TLS 1.2, namely RC4 and Cipher Block Chaining (CBC) cipher suites, suffer from several weaknesses. RC4 has exploitable biases in its key stream; see [RFC7465]. CBC cipher suites have been a source of vulnerabilities over 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 🙈

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] 😱

Finally, while application-layer traffic in TLS 1.2 is always encrypted, most of the content of the handshake messages is not. So the privacy it provides is suboptimal. This is a protocol issue that can't be fixed by configuration 🥲

7. IANA Considerations 🌷

This document has no IANA actions ✨

8. References 📚

8.1. Normative References

8.2. Informative References ✨

okay bestie, these are the receipts 🧾 the extra reading that backs up everything above, no cap 💅

Authors' Addresses 🎀

Rich Salz
Akamai Technologies
Email: rsalz@akamai.com


Nimrod Aviram
Email: nimrod.aviram@gmail.com
📦 where this page comes from