1. Introduction

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide variety of application protocols, including HTTP [RFC9112] [RFC9113], IMAP [RFC9051], Post Office Protocol (POP) [STD53], SIP [RFC3261], SMTP [RFC5321], and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. Such protocols use both the TLS or DTLS handshake protocol and the TLS or DTLS record layer. Although the TLS handshake protocol can also be used with different record layers to define secure transport protocols (the most prominent example is QUIC [RFC9000]), such transport protocols are not directly in scope for this document; nevertheless, many of the recommendations here might apply insofar as such protocols use the TLS handshake protocol.

Over the years leading to 2015, the industry had witnessed serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. For instance, both the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which together were once the most widely deployed ciphers, were attacked in the context of TLS. Detailed information about the attacks known prior to 2015 is provided in a companion document [RFC7457] to the previous version of the TLS recommendations [RFC7525], which will help the reader understand the rationale behind the recommendations provided here. That document has not been updated in concert with this one; instead, newer attacks are described in this document, as are mitigations for those attacks.

The TLS community reacted to the attacks described in [RFC7457] in several ways:

Detailed guidance was published on the use of TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347] along with earlier protocol versions. This guidance is included in the original [RFC7525] and mostly retained in this revised version; note that this guidance was mostly adopted by the industry since the publication of RFC 7525 in 2015.
Versions of TLS earlier than 1.2 were deprecated [RFC8996].
Version 1.3 of TLS [RFC8446] was released, followed by version 1.3 of DTLS [RFC9147]; these versions largely mitigate or resolve the described attacks.

Those who implement and deploy TLS and TLS-based protocols need guidance on how they can be used securely. This document provides guidance for deployed services as well as for software implementations, assuming the implementer expects their code to be deployed in the environments defined in Section 5. Concerning deployment, this document targets a wide audience, namely all deployers who wish to add authentication (be it one-way only or mutual), confidentiality, and data integrity protection to their communications.

The recommendations herein take into consideration the security of various mechanisms, their technical maturity and interoperability, and their prevalence in implementations at the time of writing. Unless it is explicitly called out that a recommendation applies to TLS alone or to DTLS alone, each recommendation applies to both TLS and DTLS.

This document attempts to minimize new guidance to TLS 1.2 implementations, and the overall approach is to encourage systems to move to TLS 1.3. However, this is not always practical. Newly discovered attacks, as well as ecosystem changes, necessitated some new requirements that apply to TLS 1.2 environments. Those are summarized in Appendix A.

Naturally, future attacks are likely, and this document cannot address them. Those who implement and deploy TLS/DTLS and protocols based on TLS/DTLS are strongly advised to pay attention to future developments. In particular, although it is known that the creation of quantum computers will have a significant impact on the security of cryptographic primitives and the technologies that use them, currently post-quantum cryptography is a work in progress and it is too early to make recommendations; once the relevant specifications are standardized in the IETF or elsewhere, this document should be updated to reflect best practices at that time.

As noted, the TLS 1.3 specification resolves many of the vulnerabilities listed in this document. A system that deploys TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below. Therefore, this document replaces [RFC7525], with an explicit goal to encourage migration of most uses of TLS 1.2 to TLS 1.3.

These are minimum recommendations for the use of TLS in the vast majority of implementation and deployment scenarios, with the exception of unauthenticated TLS (see Section 5). Other specifications that reference this document can have stricter requirements related to one or more aspects of the protocol, based on their particular circumstances (e.g., for use with a specific application protocol); when that is the case, implementers are advised to adhere to those stricter requirements. Furthermore, this document provides a floor, not a ceiling: where feasible, administrators of services are encouraged to go beyond the minimum support available in implementations to provide the strongest security possible. For example, based on knowledge about the deployed base for an existing application protocol and a cost-benefit analysis regarding security strength vs. interoperability, a given service provider might decide to disable TLS 1.2 entirely and offer only TLS 1.3.

Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document.

This document updates [RFC5288] in view of the [Boeck2016] attack. See Section 7.2.1 for the details.

This document updates [RFC6066] in view of the [ALPACA] attack. See Section 3.7 for the details.