RFC 7525

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

📅 published May 2015, from ietf

RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 🎀

okay so the title block first 💅

  • Series: Internet Engineering Task Force (IETF), Request for Comments 7525 🦋
  • Authors: Y. Sheffer (Intuit), R. Holz (NICTA), and P. Saint-Andre (&yet) 💖
  • Category: Best Current Practice, which is BCP 195 👑
  • ISSN: 2070-1721
  • Date: May 2015
  • Obsoletes / Updates: the title block doesn't list any, so there's nothing it replaces or changes 🌸

Abstract ✨

okay so TLS and DTLS are the bodyguards for tons of app protocols, like HTTP, SMTP, IMAP, POP, SIP, and XMPP 🛡️ but over the last few years a bunch of seriously bad attacks showed up, and they hit the most popular cipher suites and how they run 💀 this doc gives recommendations for making deployed TLS and DTLS services more secure. the good news is they apply to most use cases 🫶

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741 📚

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7525 🔗

Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, bestie, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚

Table of Contents 📋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
3.  General Recommendations . . . . . . . . . . . . . . . . . . .   5
  3.1.  Protocol Versions . . . . . . . . . . . . . . . . . . . .   5
    3.1.1.  SSL/TLS Protocol Versions . . . . . . . . . . . . . .   5
    3.1.2.  DTLS Protocol Versions  . . . . . . . . . . . . . . .   6
    3.1.3.  Fallback to Lower Versions  . . . . . . . . . . . . .   7
  3.2.  Strict TLS  . . . . . . . . . . . . . . . . . . . . . . .   7
  3.3.  Compression . . . . . . . . . . . . . . . . . . . . . . .   8
  3.4.  TLS Session Resumption  . . . . . . . . . . . . . . . . .   8
  3.5.  TLS Renegotiation . . . . . . . . . . . . . . . . . . . .   9
  3.6.  Server Name Indication  . . . . . . . . . . . . . . . . .   9
4.  Recommendations: Cipher Suites  . . . . . . . . . . . . . . .   9
  4.1.  General Guidelines  . . . . . . . . . . . . . . . . . . .   9
  4.2.  Recommended Cipher Suites . . . . . . . . . . . . . . . .  11
    4.2.1.  Implementation Details  . . . . . . . . . . . . . . .  12
  4.3.  Public Key Length . . . . . . . . . . . . . . . . . . . .  12
  4.4.  Modular Exponential vs. Elliptic Curve DH Cipher Suites .  13
  4.5.  Truncated HMAC  . . . . . . . . . . . . . . . . . . . . .  14
5.  Applicability Statement . . . . . . . . . . . . . . . . . . .  15
  5.1.  Security Services . . . . . . . . . . . . . . . . . . . .  15
  5.2.  Opportunistic Security  . . . . . . . . . . . . . . . . .  16
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
  6.1.  Host Name Validation  . . . . . . . . . . . . . . . . . .  17
  6.2.  AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . .  18
  6.3.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  18
  6.4.  Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . .  19
  6.5.  Certificate Revocation  . . . . . . . . . . . . . . . . .  19
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  26
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1. Introduction ✨

okay so TLS [RFC5246] and Datagram Transport Security Layer (DTLS) [RFC6347] are everywhere protecting data for app protocols like HTTP, SMTP, IMAP, POP, SIP, and XMPP 🫶 and over the last few years, a lot of serious attacks hit TLS, especially its most used cipher suites and their modes of operation 😭 for instance, both the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms have been attacked in the TLS context, and together they were the most widely deployed ciphers 💀 a companion doc [RFC7457] digs into those attacks in detail, so you can see why these recommendations exist 🔍

because of all this, the people who build and run TLS and DTLS need fresh guidance on using TLS safely 🛡️ this doc covers deployed services and software implementations, assuming the implementer expects their code to be deployed in the environments defined in Section 5 🌸 fun twist: it actually calls for algorithms that are widely implemented but not yet widely deployed 👀 the target audience is pretty huge, basically every deployer who wants to add authentication (one-way or mutual), confidentiality, and data integrity protection to their communications 💜

the recommendations take into account how secure each mechanism is, how mature and interoperable it is, and how common it is in implementations when this was written 🧠 unless it's explicitly said that a recommendation applies only to TLS or only to DTLS, it applies to both 🦋

it's expected that TLS 1.3 will fix many of the vulnerabilities listed here ✨ a system that deploys TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below 🎉 this doc will probably get updated once TLS 1.3 gets noticeable deployment 🔄

these are minimum recommendations for using TLS in the vast majority of implementation and deployment scenarios, except for unauthenticated TLS (see Section 5) 🙈 other specs that reference this doc can have stricter requirements about one or more aspects of the protocol, based on their own situation (for example, for use with a particular application protocol), and when that happens, implementers are advised to follow those stricter requirements 🧚 also, this doc is a floor, not a ceiling, so stronger options are always allowed (for example, depending on how people weigh cryptographic strength against computational load) 💪

the security world moves fast! community knowledge about how strong algorithms are and which attacks are feasible can change quickly, and experience shows that a Best Current Practice document about security is a snapshot in time 📸 readers should go looking for any errata or updates that apply to this doc 🔎

2. Terminology 📖

a bunch of the security terms in this doc are used in the sense defined in [RFC4949] 🤓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🎀

3. General Recommendations 🌷

this section has general recommendations for using TLS securely 💖 the cipher suite recommendations come in the next section 🦋

3.1. Protocol Versions 🌈

3.1.1. SSL/TLS Protocol Versions

it's important to both stop using the old, less secure versions of SSL/TLS and start using the modern, more secure ones 🚫 so here are the recommendations on TLS/SSL protocol versions 👑

  • Implementations MUST NOT negotiate SSL version 2.

Rationale: SSLv2 is considered insecure today [RFC6176]. 💀

  • Implementations MUST NOT negotiate SSL version 3.

Rationale: SSLv3 [RFC6101] was an upgrade from SSLv2 and patched some big security holes, but it didn't support strong cipher suites 🩹 it also doesn't support TLS extensions, and some of those, like renegotiation_info [RFC5746], are security-critical 😱 on top of that, with the POODLE attack [POODLE] showing up, SSLv3 is now widely recognized as fundamentally insecure 🙅‍♀️ see [DEP-SSLv3] for more details 📎

  • Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation.

Rationale: TLS 1.0 (published in 1999) doesn't support many modern, strong cipher suites 🥲 it also lacks a per-record Initialization Vector (IV) for CBC-based cipher suites and doesn't warn against common padding errors 🙈

  • Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]; the only exception is when no higher version is available in the negotiation.

Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0, but it still doesn't support certain stronger cipher suites 📈

  • Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. ⭐

Rationale: several stronger cipher suites are only available with TLS 1.2 (published in 2008) 🔥 in fact, the cipher suites this doc recommends (Section 4.2 below) are only available in TLS 1.2 💖

this BCP applies to TLS 1.2 and to earlier versions too 📜 it's not safe for readers to assume the recommendations in this BCP apply to any future version of TLS 🔮

3.1.2. DTLS Protocol Versions

DTLS, which is basically TLS adapted for UDP datagrams, came out when TLS 1.1 was published 🦋 here's what this doc recommends for DTLS:

  • Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347].

DTLS version 1.0 lines up with TLS version 1.1 (see above). 🧩

  • Implementations MUST support and MUST prefer to negotiate DTLS version 1.2 [RFC6347].

DTLS version 1.2 lines up with TLS version 1.2 (see above). (There is no DTLS version 1.1.) 🫶

3.1.3. Fallback to Lower Versions 🦋

okay bestie, clients that "fall back" to lower versions after the server rejects higher ones MUST NOT fall back to SSLv3 or earlier 🙅‍♀️ no cap, that's a hard no.

Rationale: some client implementations go back to lower versions of TLS, or even to SSLv3, if the server rejected the higher versions 😭. A man-in-the-middle (MITM) attacker can force that fallback, and it's giving danger. TLS 1.0 and SSLv3 are way less secure than TLS 1.2, which is the version this document recommends 💅. TLS 1.0-only servers are still pretty common, but IP scans show SSLv3-only servers are only about 3% of the current Web server population 🌸. (At the time of writing, an explicit method for preventing downgrade attacks was recently defined in [RFC7507].)

3.2. Strict TLS 🔒

The following recommendations help prevent SSL Stripping (an attack summarized in Section 2.1 of [RFC7457]) 🙈:

  • In cases where an application protocol lets implementations or deployments choose between a strict TLS configuration and a dynamic upgrade from unencrypted to TLS-protected traffic (like STARTTLS), clients and servers SHOULD prefer strict TLS configuration 💖.
  • Application protocols usually give the server a way to offer TLS during an initial protocol exchange, and sometimes a way to advertise TLS support (like a flag saying TLS is required). Unfortunately, these indications are sent before the channel is encrypted 😤. A client SHOULD attempt to negotiate TLS even if the server doesn't communicate these indications 🫶.
  • HTTP client and server implementations MUST support the HTTP Strict Transport Security (HSTS) header [RFC6797], so Web servers can advertise that they're willing to accept TLS-only clients ✨.
  • Web servers SHOULD use HSTS to indicate they're willing to accept TLS-only clients, unless they're deployed in a way where using HSTS would actually weaken overall security (for example, it can be problematic to use HSTS with self-signed certificates, as described in Section 11.3 of [RFC6797]) 💀.

Rationale: combining unprotected and TLS-protected communication opens the door to SSL Stripping and similar attacks. An initial part of the communication isn't integrity protected, so an attacker who wants to keep things in the clear can manipulate it 🚨.

SSL Stripping is the main villain here, bestie 🦹

3.3. Compression 🗜️

To help prevent compression-related attacks (summarized in Section 2.6 of [RFC7457]), implementations and deployments SHOULD disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless the application protocol in question has been shown not to be open to such attacks 🙌.

Rationale: TLS compression has been subject to security attacks, like the CRIME attack 😱.

Implementers should note that compression at higher protocol levels can allow an active attacker to extract cleartext information from the connection. The BREACH attack is one such case. These issues can only be mitigated outside of TLS, so they're outside the scope of this document. See Section 2.6 of [RFC7457] for further details 📚.

3.4. TLS Session Resumption 🎫

If TLS session resumption is used, care ought to be taken to do it safely. In particular, when using session tickets [RFC5077], the resumption information MUST be authenticated and encrypted to prevent modification or eavesdropping by an attacker 🔐. Further recommendations apply to session tickets:

  • A strong cipher suite MUST be used when encrypting the ticket (as least as strong as the main TLS cipher suite).
  • Ticket keys MUST be changed regularly, e.g., once every week, so as not to negate the benefits of forward secrecy (see Section 6.3 for details on forward secrecy).
  • For similar reasons, session ticket validity SHOULD be limited to a reasonable duration (e.g., half as long as ticket key validity) ⏳.

Rationale: session resumption is another kind of TLS handshake, so it must be as secure as the initial handshake 💅. This document (Section 4) recommends cipher suites that provide forward secrecy, meaning they prevent an attacker who gains momentary access to the TLS endpoint (either client or server) and its secrets from reading either past or future communication 🕵️. The tickets have to be managed so they don't negate this security property 🧚.

3.5. TLS Renegotiation 🔁

Where handshake renegotiation is implemented, both clients and servers MUST implement the renegotiation_info extension, as defined in [RFC5746] 🫶.

The most secure option for countering the Triple Handshake attack is to refuse any change of certificates during renegotiation. In addition, TLS clients SHOULD apply the same validation policy for all certificates received over a connection 👀. The [triple-handshake] document suggests several other possible countermeasures, such as binding the master secret to the full handshake (see [SESSION-HASH]) and binding the abbreviated session resumption handshake to the original full handshake. Although the latter two techniques are still under development and thus don't qualify as current practices, those who implement and deploy TLS are advised to watch for further development of appropriate countermeasures 🔭.

3.6. Server Name Indication 🏷️

TLS implementations MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066] for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy 🗺️.

Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single address, and therefore enables fine-grained security for these virtual servers, because each one can have its own certificate 🌈.

4. Recommendations: Cipher Suites 🎀

TLS and its implementations give you considerable flexibility when selecting cipher suites. Unfortunately, some available cipher suites are insecure, some don't provide the targeted security services, and some no longer provide enough security. Configuring a server incorrectly leads to no security or reduced security 😬. This section includes recommendations on the selection and negotiation of cipher suites 💜.

4.1. General Guidelines 📜

Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Those algorithms need to be phased out over time and replaced with more secure cipher suites, which helps make sure the desired security properties still hold 🔄. SSL/TLS has been around for almost 20 years, and many of the cipher suites recommended in various versions of SSL/TLS are now considered weak, or at least not as strong as we'd like. So this section modernizes the recommendations about cipher suite selection ✨.

  • Implementations MUST NOT negotiate the cipher suites with NULL encryption.

Rationale: NULL cipher suites don't encrypt traffic, so they provide no confidentiality. Anybody in the network with access to the connection can read the plaintext of what the client and server exchange 👀. (Nevertheless, this document does not discourage software from implementing NULL cipher suites, since they can be useful for testing and debugging 🧪.)

  • Implementations MUST NOT negotiate RC4 cipher suites.

Rationale: the RC4 stream cipher has a variety of cryptographic weaknesses, as documented in [RFC7465]. Note that DTLS already specifically forbids the use of RC4 🙅‍♀️.

  • Implementations MUST NOT negotiate cipher suites offering less than 112 bits of security, including so-called "export-level" encryption (which provides 40 or 56 bits of security) 🚫.

Rationale: based on [RFC3766], at least 112 bits of security is needed. 40-bit and 56-bit security are considered insecure today. TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers 🙌.

  • Implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security.

Rationale: cipher suites offering between 112 and 128 bits of security aren't considered weak at this time. However, their useful lifespan is expected to be short enough to justify supporting stronger cipher suites right now. 128-bit ciphers are expected to stay secure for at least several years, and 256-bit ciphers until the next fundamental technology breakthrough 🔮. Note that, because of so-called "meet-in-the-middle" attacks [Multiple-Encryption], some legacy cipher suites (e.g., 168-bit 3DES) have an effective key length that's smaller than their nominal key length (112 bits in the case of 3DES). Such cipher suites should be evaluated according to their effective key length 🧐.

  • Implementations SHOULD NOT negotiate cipher suites based on RSA key transport, a.k.a. "static RSA".

Rationale: these cipher suites, which have assigned values starting with the string TLS_RSA_WITH_*, have several drawbacks. Especially, they don't support forward secrecy 💔.

  • Implementations MUST support and prefer to negotiate cipher suites offering forward secrecy, such as those in the Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and "ECDHE") families 🔥.

Rationale: forward secrecy (sometimes called "perfect forward secrecy") prevents the recovery of information that was encrypted with older session keys, which limits the amount of time during which attacks can be successful ⏰. See Section 6.3 for a detailed discussion.

Given the foregoing considerations, implementing and deploying the following cipher suites is RECOMMENDED 👑:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

These cipher suites are supported only in TLS 1.2 because they are authenticated encryption (AEAD) algorithms [RFC5116] 🧁.

Typically, in order to prefer these suites, the order of suites needs to be explicitly configured in server software. (See [BETTERCRYPTO] for helpful deployment guidelines, but note that its recommendations differ from the current document in some details 📖.) It would be ideal if server software implementations preferred these suites by default 🥹.

Some devices have hardware support for AES-CCM but not AES-GCM, so they're unable to follow the foregoing recommendations regarding cipher suites 🙃. There are even devices that don't support public key cryptography at all, but they're out of scope entirely 🫠.

4.2.1. Implementation Details ✨

okay so, clients SHOULD put TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the very first proposal to any server 💖, unless they already know the server can't respond to a TLS 1.2 client_hello message 🙈.

Servers MUST prefer this cipher suite over weaker ones whenever it's proposed, even if it isn't the first thing on the list 👑.

Clients are totally free to offer stronger cipher suites, like the ones using AES-256 💅. When they do, the server SHOULD prefer the stronger one, unless there are compelling reasons (like seriously degraded performance 💀) to pick something else.

This document does not change the mandatory-to-implement TLS cipher suite(s) that TLS already prescribes 🎀. To keep things interoperable, RFC 5246 mandates TLS_RSA_WITH_AES_128_CBC_SHA, which is significantly weaker than the cipher suites recommended here 😭. (GCM mode doesn't have the same weakness, which comes from the MAC-then-Encrypt order in TLS [Krawczyk2001], since it uses an AEAD mode of operation ✨.) Implementers should weigh the interoperability gain against the loss in security when deploying TLS_RSA_WITH_AES_128_CBC_SHA 🦋. Other application protocols specify other cipher suites as mandatory to implement (MTI) 🌸.

Some profiles of TLS 1.2 use different cipher suites, which is giving variety 🌈. For example, [RFC6460] defines a profile that uses TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 🧚.

[RFC4492] lets clients and servers negotiate ECDH parameters (curves) 🍓. Both clients and servers SHOULD include the "Supported Elliptic Curves" extension [RFC4492]. For interoperability, clients and servers SHOULD support the NIST P-256 (secp256r1) curve [RFC4492] 💜. Also, clients SHOULD send an ec_point_formats extension with a single element, "uncompressed" 🫶.

4.3. Public Key Length

okay this one is lowkey important 🔥. When you use the cipher suites recommended in this document, two public keys are normally used in the TLS handshake: one for the Diffie-Hellman key agreement, and one for server authentication 🔑. If a client certificate is used, a third public key gets added 🎀.

With a key exchange based on modular exponential (MODP) Diffie-Hellman groups (the "DHE" cipher suites), DH key lengths of at least 2048 bits are RECOMMENDED ✨.

Rationale: In practice, DH keys are typically generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 2^11 = 2048 bits, 2^12 = 4096 bits) 🌸. A DH key of 1228 bits would be roughly equivalent to only an 80-bit symmetric key [RFC3766], so it's better to use keys longer than that for the "DHE" family of cipher suites 😭. A DH key of 1926 bits would be roughly equivalent to a 100-bit symmetric key [RFC3766], and a DH key of 2048 bits might be sufficient for at least the next 10 years [NIST.SP.800-56A] 💅. See Section 4.4 for additional information on the use of MODP Diffie-Hellman in TLS 🦋.

As noted in [RFC3766], correcting for the emergence of a TWIRL machine would imply that 1024-bit DH keys yield about 65 bits of equivalent strength, and that a 2048-bit DH key would yield about 92 bits of equivalent strength 🙈.

With regard to ECDH keys, the IANA "EC Named Curve Registry" (within the "Transport Layer Security (TLS) Parameters" registry [IANA-TLS]) contains 160-bit elliptic curves that are considered to be roughly equivalent to only an 80-bit symmetric key [ECRYPT-II] 💀. Curves of less than 192 bits SHOULD NOT be used 🚫.

When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key 🔐. The use of the SHA-256 hash algorithm is RECOMMENDED too (see [CAB-Baseline] for more details) 👑. Clients SHOULD indicate to servers that they request SHA-256 by using the "Signature Algorithms" extension defined in TLS 1.2 🫶.

4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites

Not every TLS implementation supports both modular exponential (MODP) and elliptic curve (EC) Diffie-Hellman groups, even though Section 4.2 asks for them 😭. Some implementations are severely limited in the length of DH values 💔. When those implementations need to be accommodated, the following are RECOMMENDED (in priority order) 🌈:

  1. Elliptic Curve DHE with appropriately negotiated parameters (e.g., the curve to be used) and a Message Authentication Code (MAC) algorithm stronger than HMAC-SHA1 [RFC5289] 🧚
  2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit Diffie-Hellman parameters 💜
  3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters 🙈

Rationale: Elliptic Curve Cryptography is widely deployed, but there are some communities where adoption has been limited for several reasons 🍓. These include its complexity compared to modular arithmetic, and longstanding perceptions of IPR concerns (which, for the most part, have now been resolved [RFC6090]) 💅. Note that ECDHE cipher suites exist for both RSA and ECDSA certificates, so moving to ECDHE cipher suites does not require moving away from RSA-based certificates ✨. On the other hand, there are two related issues hindering effective use of MODP Diffie-Hellman cipher suites in TLS 😤:

  • There are no standardized, widely implemented protocol mechanisms to negotiate the DH groups or parameter lengths supported by client and server 🤷‍♀️.
  • Many servers choose DH parameters of 1024 bits or fewer 💀.
  • There are widely deployed client implementations that reject received DH parameters if they are longer than 1024 bits 🚫. In addition, several implementations do not perform appropriate validation of group parameters, and are vulnerable to attacks referenced in Section 2.9 of [RFC7457] 😱.

Note that with DHE and ECDHE cipher suites, the TLS master key only depends on the Diffie-Hellman parameters and not on the strength of the RSA certificate 🔑. Moreover, 1024-bit MODP DH parameters are generally considered insufficient at this time 🙅‍♀️.

With MODP ephemeral DH, deployers ought to carefully evaluate interoperability vs. security considerations when configuring their TLS endpoints 🫶.

4.5. Truncated HMAC

Implementations MUST NOT use the Truncated HMAC extension, defined in Section 7 of [RFC6066] 🚫. This one is a hard no, bestie 💀.

Rationale: The extension doesn't apply to the AEAD cipher suites recommended above 🙈. However, it does apply to most other TLS cipher suites 🫠. Its use has been shown to be insecure in [PatersonRS11] 😭.

5. Applicability Statement

The recommendations of this document mainly apply to the implementation and deployment of application protocols that are most commonly used with TLS and DTLS on the Internet today 🌐. Examples include, but are not limited to:

  • Web software and services that want to protect HTTP traffic with TLS 🌸.
  • Email software and services that want to protect IMAP, POP3, or SMTP traffic with TLS 💌.
  • Instant-messaging software and services that want to protect Extensible Messaging and Presence Protocol (XMPP) or Internet Relay Chat (IRC) traffic with TLS 💬.
  • Realtime media software and services that want to protect Secure Realtime Transport Protocol (SRTP) traffic with DTLS 🎥.

This document does not modify the implementation and deployment recommendations (e.g., mandatory-to-implement cipher suites) prescribed by existing application protocols that employ TLS or DTLS 🙅‍♀️. If the community that uses such an application protocol wants to modernize its usage of TLS or DTLS to match the best practices recommended here, it needs to explicitly update the existing application protocol definition (one example is [TLS-XMPP], which updates [RFC6120]) 🦋.

Designers of new application protocols developed through the Internet Standards Process [RFC2026] are expected, at minimum, to conform to the best practices recommended here 👑. The exception is if they provide documentation of compelling reasons that would prevent that conformance (e.g., widespread deployment on constrained devices that lack support for the necessary algorithms) 🧸.

5.1. Security Services

This document gives recommendations for an audience that wants to secure their communication with TLS to achieve the following 🔒:

  • Confidentiality: all application-layer communication is encrypted, with the goal that no party should be able to decrypt it except the intended receiver 🤫.
  • Data integrity: any changes made to the communication in transit are detectable by the receiver 🕵️‍♀️.
  • Authentication: an endpoint of the TLS communication is authenticated as the intended entity to communicate with 🪪.

With regard to authentication, TLS enables authentication of one or both endpoints in the communication 🤝. In the context of opportunistic security [RFC7435], TLS is sometimes used without authentication 🙈. As discussed in Section 5.2, considerations for opportunistic security are not in scope for this document 🌸.

If deployers deviate from the recommendations given in this document, they need to be aware that they might lose access to one of the security services above 😬.

This document applies only to environments where confidentiality is required 🔐. It recommends algorithms and configuration options that enforce secrecy of the data in transit 🤐.

This document also assumes that data integrity protection is always one of the goals of a deployment 🛡️. In cases where integrity is not required, it doesn't make sense to use TLS in the first place 🙃. There are attacks against confidentiality-only protection that use the lack of integrity to also break confidentiality (see, for instance, [DegabrieleP07] in the context of IPsec) 💀.

This document addresses application protocols that are most commonly used on the Internet with TLS and DTLS 🌍. Typically, all communication between TLS clients and TLS servers requires all three of the above security services 💯. This is especially true where TLS clients are user agents like Web browsers or email software 🦋.

This document does not address the rarer deployment scenarios where one of the above three properties is not desired, such as the use case described in Section 5.2 below 🧐. Another scenario where confidentiality isn't needed is a monitored network where the authorities in charge of the traffic domain require full access to unencrypted (plaintext) traffic, and where users collaborate and send their traffic in the clear 👀.

5.2. Opportunistic Security

There are several important scenarios where the use of TLS is optional 🎲. This means the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear 🤷‍♀️. This practice, often called "opportunistic security", is described at length in [RFC7435] and is often motivated by a desire for backward compatibility with legacy deployments 🕰️.

In these scenarios, some of the recommendations in this document might be too strict, since following them could cause fallback to cleartext 😱. That's a worse outcome than using TLS with an outdated protocol version or cipher suite 💀.

This document specifies best practices for TLS in general 📘. A separate document with recommendations for the use of TLS with opportunistic security is to be completed in the future 🔮.

6. Security Considerations

This entire document discusses the security practices that directly affect applications using the TLS protocol 🛡️🔥. This section contains broader security considerations related to technologies used in conjunction with or by TLS 🚨.

6.1. Host Name Validation 🎀

Okay bestie, heads up for app authors 🚨. Some TLS implementations just don't validate host names, and that's a whole thing. If yours is one of them, you might need to write your own validation code or switch to a different TLS implementation 🛠️.

Host name validation rules (and honestly, how the TLS layer gets tied to the protocol running on top of it) are different for each protocol. For HTTPS, those rules are set by Section 3 of [RFC2818] 🔒.

If you want the generic host name validation details in the TLS context, go check [RFC6125] 📖. It also has a looong list of example protocols, and some of them do things super differently from HTTPS, so don't assume anything 👀.

If a host name was found indirectly and insecurely (like through an insecure DNS query for an MX or SRV record), it SHOULD NOT be used as a reference identifier [RFC6125], even if it matches the presented certificate 🙅‍♀️. This doesn't apply if the host name was found securely. For more on that, see [DANE-SRV] and [DANE-SMTP] ✨.

Host name validation usually only applies to the leaf "end entity" certificate. But to get proper authentication in the PKI context, application clients need to verify the entire certification path under [RFC5280] (also see [RFC6125]) 🫶.

6.2. AES-GCM 🔐

Section 4.2 above recommends AES-GCM authenticated encryption, and it's giving main character energy 👑. For general security considerations when you're using TLS 1.2, check Section 11 of [RFC5246]. For the ones that apply specifically to AES-GCM with TLS, check Section 6 of [RFC5288] 💅.

6.3. Forward Secrecy 🦋

Forward secrecy (also called "perfect forward secrecy" or "PFS," and defined in [RFC4949]) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties' long-term keys 👀. If that attacker gets those long-term keys later on, the session keys and the entire conversation could be decrypted 💀.

In TLS and DTLS, long-term key compromise is not entirely implausible, ngl 😬. It can happen, for example, due to:

  • A client or server being attacked by some other attack vector, and the private key retrieved.
  • A long-term key retrieved from a device that has been sold or otherwise decommissioned without prior wiping.
  • A long-term key used on a device as a default key [Heninger2012].
  • A key generated by a trusted third party like a CA, and later retrieved from it either by extortion or compromise [Soghoian2011].
  • A cryptographic break-through, or the use of asymmetric keys with insufficient length [Kleinjung2010].
  • Social engineering attacks against system administrators.
  • Collection of private keys from inadequately protected backups.

So in those cases, forward secrecy makes sure it's not feasible for an attacker to figure out the session keys, even if they got the long-term keys some time after the conversation 🔒. It also protects against an attacker who has the long-term keys but stays passive during the conversation 🫣.

Forward secrecy is generally achieved by using the Diffie-Hellman scheme to derive session keys 🧚. With this scheme, both parties keep private secrets and send parameters over the network as modular powers over certain cyclic groups. The properties of the so-called Discrete Logarithm Problem (DLP) let the parties derive the session keys without an eavesdropper being able to do the same. There's no known attack against DLP as long as sufficiently large parameters are chosen 🌸. There's also a variant of Diffie-Hellman that uses Elliptic Curves instead of the originally proposed modular arithmetic ✨.

Unfortunately, a lot of TLS/DTLS cipher suites were defined without forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256 😩. So this document advocates strict use of forward-secrecy-only ciphers, and I'm 100% here for it 💖.

6.4. Diffie-Hellman Exponent Reuse 🍓

For performance reasons, a lot of TLS implementations reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multiple connections 🏎️. But this can cause some major security issues 🚨:

  • If exponents are reused for too long (e.g., even more than a few hours), an attacker who gains access to the host can decrypt previous connections. In other words, exponent reuse negates the effects of forward secrecy 💔.
  • TLS implementations that reuse exponents should test the DH public key they receive for group membership, so they can avoid some known attacks 🙈. These tests aren't standardized in TLS at the time of writing. For the recipient tests that IKEv2 implementations which reuse DH exponents are required to do, see [RFC6989] 📚.

6.5. Certificate Revocation 🚫

The following considerations and recommendations represent the current state of the art for certificate revocation 💅. Even so, no complete and efficient solution exists for checking the revocation status of common public key certificates [RFC5280], so here's the tea 🫖:

  • Certificate Revocation Lists (CRLs) are the most widely supported mechanism for distributing revocation information, but they have known scaling challenges that limit their usefulness (despite workarounds such as partitioned CRLs and delta CRLs) 😮‍💨.
  • Proprietary mechanisms that embed revocation lists in the Web browser's configuration database can't scale beyond a small number of the most heavily used Web servers 🙃.
  • The On-Line Certification Status Protocol (OCSP) [RFC6960] has both scaling and privacy issues. Plus, clients typically "soft-fail," meaning they don't abort the TLS connection if the OCSP server doesn't respond. (However, this might be a workaround to avoid denial-of-service attacks if an OCSP responder is taken offline 🤷‍♀️.)
  • The TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling," resolves the operational issues with OCSP. However, it's still ineffective in the presence of a MITM attacker, because the attacker can simply ignore the client's request for a stapled OCSP response 😤.
  • OCSP stapling as defined in [RFC6066] doesn't extend to intermediate certificates used in a certificate chain. The Multiple Certificate Status extension [RFC6961] addresses this shortcoming, but it's a recent addition without much deployment yet 🌱.
  • Both CRLs and OCSP depend on relatively reliable connectivity to the Internet, which might not be available to certain kinds of nodes (such as newly provisioned devices that need to establish a secure connection in order to boot up for the first time) 🔌.

With regard to common public key certificates, servers SHOULD support the following as a best practice, given the current state of the art and as a foundation for a possible future solution 🫶:

  1. OCSP [RFC6960]
  2. Both the status_request extension defined in [RFC6066] and the status_request_v2 extension defined in [RFC6961] (This might enable interoperability with the widest range of clients.)
  3. The OCSP stapling extension defined in [RFC6961]

The considerations in this section don't apply to scenarios where the DANE-TLSA resource record [RFC6698] is used to signal to a client which certificate a server considers valid and good to use for TLS connections 🧚‍♀️.

7. References 📚

7.1. Normative References 💜

7.2. Informative References ✨

okay bestie, here's the extra reading list 📚 these aren't strictly needed to implement anything, but they're the receipts behind all the vibes 💅

[BETTERCRYPTO]
           bettercrypto.org, "Applied Crypto Hardening", April 2015,
           <https://bettercrypto.org/static/
           applied-crypto-hardening.pdf>.

[CAB-Baseline]
           CA/Browser Forum, "Baseline Requirements for the Issuance
           and Management of Publicly-Trusted Certificates Version
           1.1.6", 2013, <https://www.cabforum.org/documents.html>.

[DANE-SMTP]
           Dukhovni, V. and W. Hardaker, "SMTP security via
           opportunistic DANE TLS", Work in Progress, draft-ietf-
           dane-smtp-with-dane-16, April 2015.

[DANE-SRV] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
           Based Authentication of Named Entities (DANE) TLSA Records
           with SRV Records", Work in Progress,
           draft-ietf-dane-srv-14, April 2015.

[DEP-SSLv3]
           Barnes, R., Thomson, M., Pironti, A., and A. Langley,
           "Deprecating Secure Sockets Layer Version 3.0", Work in
           Progress, draft-ietf-tls-sslv3-diediedie-03, April 2015.

[DegabrieleP07]
           Degabriele, J. and K. Paterson, "Attacking the IPsec
           Standards in Encryption-only Configurations", IEEE
           Symposium on Security and Privacy (SP '07), 2007,
           <http://dx.doi.org/10.1109/SP.2007.8>.

[ECRYPT-II]
           Smart, N., "ECRYPT II Yearly Report on Algorithms and
           Keysizes (2011-2012)", 2012,
           <http://www.ecrypt.eu.org/ecrypt2/>.

[Heninger2012]
           Heninger, N., Durumeric, Z., Wustrow, E., and J.
           Halderman, "Mining Your Ps and Qs: Detection of Widespread
           Weak Keys in Network Devices", Usenix Security Symposium
           2012, 2012.

[IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters",
           <http://www.iana.org/assignments/tls-parameters>.

[Kleinjung2010]
           Kleinjung, T., "Factorization of a 768-Bit RSA modulus",
           CRYPTO 10, 2010, <https://eprint.iacr.org/2010/006.pdf>.

[Krawczyk2001]
           Krawczyk, H., "The Order of Encryption and Authentication
           for Protecting Communications (Or: How Secure is SSL?)",
           CRYPTO 01, 2001,
           <https://www.iacr.org/archive/crypto2001/21390309.pdf>.

[Multiple-Encryption]
           Merkle, R. and M. Hellman, "On the security of multiple
           encryption", Communications of the ACM, Vol. 24, 1981,
           <http://dl.acm.org/citation.cfm?id=358718>.

[NIST.SP.800-56A]
           Barker, E., Chen, L., Roginsky, A., and M. Smid,
           "Recommendation for Pair-Wise Key Establishment Schemes
           Using Discrete Logarithm Cryptography", NIST Special
           Publication 800-56A, 2013,
           <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
           NIST.SP.800-56Ar2.pdf>.

[POODLE]   US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE
           Attack", Alert TA14-290A, October 2014,
           <https://www.us-cert.gov/ncas/alerts/TA14-290A>.

[PatersonRS11]
           Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size
           does matter: attacks and proofs for the TLS record
           protocol", 2011,
           <http://dx.doi.org/10.1007/978-3-642-25385-0_20>.

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996,
           <http://www.rfc-editor.org/info/rfc2026>.

[RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
           RFC 2246, January 1999,
           <http://www.rfc-editor.org/info/rfc2246>.

[RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
           Algorithm and Its Use with IPsec", RFC 3602, September
           2003, <http://www.rfc-editor.org/info/rfc3602>.

[RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.1", RFC 4346, April 2006,
           <http://www.rfc-editor.org/info/rfc4346>.

[RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security", RFC 4347, April 2006,
           <http://www.rfc-editor.org/info/rfc4347>.

[RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
           "Transport Layer Security (TLS) Session Resumption without
           Server-Side State", RFC 5077, January 2008,
           <http://www.rfc-editor.org/info/rfc5077>.

[RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
           Encryption", RFC 5116, January 2008,
           <http://www.rfc-editor.org/info/rfc5116>.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, May 2008,
           <http://www.rfc-editor.org/info/rfc5280>.

[RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
           Curve Cryptography Algorithms", RFC 6090, February 2011,
           <http://www.rfc-editor.org/info/rfc6090>.

[RFC6101]  Freier, A., Karlton, P., and P. Kocher, "The Secure
           Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
           August 2011, <http://www.rfc-editor.org/info/rfc6101>.

[RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
           Protocol (XMPP): Core", RFC 6120, March 2011,
           <http://www.rfc-editor.org/info/rfc6120>.

[RFC6460]  Salter, M. and R. Housley, "Suite B Profile for Transport
           Layer Security (TLS)", RFC 6460, January 2012,
           <http://www.rfc-editor.org/info/rfc6460>.

[RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
           of Named Entities (DANE) Transport Layer Security (TLS)
           Protocol: TLSA", RFC 6698, August 2012,
           <http://www.rfc-editor.org/info/rfc6698>.

[RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
           Transport Security (HSTS)", RFC 6797, November 2012,
           <http://www.rfc-editor.org/info/rfc6797>.

[RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
           Galperin, S., and C. Adams, "X.509 Internet Public Key
           Infrastructure Online Certificate Status Protocol - OCSP",
           RFC 6960, June 2013,
           <http://www.rfc-editor.org/info/rfc6960>.

[RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
           Multiple Certificate Status Request Extension", RFC 6961,
           June 2013, <http://www.rfc-editor.org/info/rfc6961>.

[RFC6989]  Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
           Tests for the Internet Key Exchange Protocol Version 2
           (IKEv2)", RFC 6989, July 2013,
           <http://www.rfc-editor.org/info/rfc6989>.

[RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
           Most of the Time", RFC 7435, December 2014,
           <http://www.rfc-editor.org/info/rfc7435>.

[RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
           Known Attacks on Transport Layer Security (TLS) and
           Datagram TLS (DTLS)", RFC 7457, February 2015,
           <http://www.rfc-editor.org/info/rfc7457>.

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
           Suite Value (SCSV) for Preventing Protocol Downgrade
           Attacks", RFC 7507, April 2015.

[SESSION-HASH]
           Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
           Langley, A., and M. Ray, "Transport Layer Security (TLS)
           Session Hash and Extended Master Secret Extension", Work
           in Progress, draft-ietf-tls-session-hash-05, April 2015.

[Smith2013]
           Smith, B., "Proposal to Change the Default TLS
           Ciphersuites Offered by Browsers.", 2013,
           <https://briansmith.org/browser-ciphersuites-01.html>.

[Soghoian2011]
           Soghoian, C. and S. Stamm, "Certified lies: Detecting and
           defeating government interception attacks against SSL",
           Proc. 15th Int. Conf. Financial Cryptography and Data
           Security, 2011.

[TLS-XMPP] Saint-Andre, P. and a. alkemade, "Use of Transport Layer
           Security (TLS) in the Extensible Messaging and Presence
           Protocol (XMPP)", Work in Progress,
           draft-ietf-uta-xmpp-07, April 2015.

[triple-handshake]
           Delignat-Lavaud, A., Bhargavan, K., and A. Pironti,
           "Triple Handshakes Considered Harmful: Breaking and Fixing
           Authentication over TLS", 2014,
           <https://secure-resumption.com/>.

Acknowledgments 🫶

huge thank-yous to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean Turner, and Aaron Zauner for their feedback and suggested improvements 💜 Brian Smith also gets extra love for his great resource, the "Proposal to Change the Default TLS Ciphersuites Offered by Browsers" [Smith2013] 🌈 Finally, thanks to everyone who commented on the TLS, UTA, and other discussion lists but isn't named here, you're all iconic ✨

Robert Sparks and Dave Waltermire provided helpful reviews on behalf of the General Area Review Team and the Security Directorate, respectively 🎀

During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins, Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick provided comments that led to further improvements 🔥

Ralph Holz gratefully acknowledges the support by Technische Universitaet Muenchen. The authors gratefully acknowledge the assistance of Leif Johansson and Orit Levin as the working group chairs and Pete Resnick as the sponsoring Area Director 👑

Authors' Addresses 💌

Yaron Sheffer
Intuit
4 HaHarash St.
Hod HaSharon  4524075
Israel

EMail: yaronf.ietf@gmail.com


Ralph Holz
NICTA
13 Garden St.
Eveleigh 2015 NSW
Australia

EMail: ralph.ietf@gmail.com


Peter Saint-Andre
&yet

EMail: peter@andyet.com
URI:   https://andyet.com/
📦 where this page comes from