5Internet Engineering Task Force (IETF) Y. Sheffer
6Request for Comments: 9325 Intuit
8Obsoletes: 7525 Independent
9Updates: 5288, 6066 T. Fossati
10Category: Best Current Practice ARM Limited
11ISSN: 2070-1721 November 2022
14 Recommendations for Secure Use of Transport Layer Security (TLS) and
15 Datagram Transport Layer Security (DTLS)
19 Transport Layer Security (TLS) and Datagram Transport Layer Security
20 (DTLS) are used to protect data exchanged over a wide range of
21 application protocols and can also form the basis for secure
22 transport protocols. Over the years, the industry has witnessed
23 several serious attacks on TLS and DTLS, including attacks on the
24 most commonly used cipher suites and their modes of operation. This
25 document provides the latest recommendations for ensuring the
26 security of deployed services that use TLS and DTLS. These
27 recommendations are applicable to the majority of use cases.
29 RFC 7525, an earlier version of the TLS recommendations, was
30 published when the industry was transitioning to TLS 1.2. Years
31 later, this transition is largely complete, and TLS 1.3 is widely
32 available. This document updates the guidance given the new
33 environment and obsoletes RFC 7525. In addition, this document
34 updates RFCs 5288 and 6066 in view of recent attacks.
38 This memo documents an Internet Best Current Practice.
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Further information on
44 BCPs is available in Section 2 of RFC 7841.
46 Information about the current status of this document, any errata,
47 and how to provide feedback on it may be obtained at
48 https://www.rfc-editor.org/info/rfc9325.
52 Copyright (c) 2022 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (https://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Revised BSD License text as described in Section 4.e of the
62 Trust Legal Provisions and are provided without warranty as described
63 in the Revised BSD License.
69 3. General Recommendations
70 3.1. Protocol Versions
71 3.1.1. SSL/TLS Protocol Versions
72 3.1.2. DTLS Protocol Versions
73 3.1.3. Fallback to Lower Versions
76 3.3.1. Certificate Compression
77 3.4. TLS Session Resumption
78 3.5. Renegotiation in TLS 1.2
79 3.6. Post-Handshake Authentication
80 3.7. Server Name Indication (SNI)
81 3.8. Application-Layer Protocol Negotiation (ALPN)
82 3.9. Multi-Server Deployment
83 3.10. Zero Round-Trip Time (0-RTT) Data in TLS 1.3
84 4. Recommendations: Cipher Suites
85 4.1. General Guidelines
86 4.2. Cipher Suites for TLS 1.2
87 4.2.1. Implementation Details
88 4.3. Cipher Suites for TLS 1.3
89 4.4. Limits on Key Usage
90 4.5. Public Key Length
92 5. Applicability Statement
93 5.1. Security Services
94 5.2. Opportunistic Security
95 6. IANA Considerations
96 7. Security Considerations
97 7.1. Host Name Validation
99 7.2.1. Nonce Reuse in TLS 1.2
101 7.4. Diffie-Hellman Exponent Reuse
102 7.5. Certificate Revocation
104 8.1. Normative References
105 8.2. Informative References
106 Appendix A. Differences from RFC 7525
112 Transport Layer Security (TLS) and Datagram Transport Layer Security
113 (DTLS) are used to protect data exchanged over a wide variety of
114 application protocols, including HTTP [RFC9112] [RFC9113], IMAP
115 [RFC9051], Post Office Protocol (POP) [STD53], SIP [RFC3261], SMTP
116 [RFC5321], and the Extensible Messaging and Presence Protocol (XMPP)
117 [RFC6120]. Such protocols use both the TLS or DTLS handshake
118 protocol and the TLS or DTLS record layer. Although the TLS
119 handshake protocol can also be used with different record layers to
120 define secure transport protocols (the most prominent example is QUIC
121 [RFC9000]), such transport protocols are not directly in scope for
122 this document; nevertheless, many of the recommendations here might
123 apply insofar as such protocols use the TLS handshake protocol.
125 Over the years leading to 2015, the industry had witnessed serious
126 attacks on TLS and DTLS, including attacks on the most commonly used
127 cipher suites and their modes of operation. For instance, both the
128 AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which
129 together were once the most widely deployed ciphers, were attacked in
130 the context of TLS. Detailed information about the attacks known
131 prior to 2015 is provided in a companion document [RFC7457] to the
132 previous version of the TLS recommendations [RFC7525], which will
133 help the reader understand the rationale behind the recommendations
134 provided here. That document has not been updated in concert with
135 this one; instead, newer attacks are described in this document, as
136 are mitigations for those attacks.
138 The TLS community reacted to the attacks described in [RFC7457] in
141 * Detailed guidance was published on the use of TLS 1.2 [RFC5246]
142 and DTLS 1.2 [RFC6347] along with earlier protocol versions. This
143 guidance is included in the original [RFC7525] and mostly retained
144 in this revised version; note that this guidance was mostly
145 adopted by the industry since the publication of RFC 7525 in 2015.
147 * Versions of TLS earlier than 1.2 were deprecated [RFC8996].
149 * Version 1.3 of TLS [RFC8446] was released, followed by version 1.3
150 of DTLS [RFC9147]; these versions largely mitigate or resolve the
153 Those who implement and deploy TLS and TLS-based protocols need
154 guidance on how they can be used securely. This document provides
155 guidance for deployed services as well as for software
156 implementations, assuming the implementer expects their code to be
157 deployed in the environments defined in Section 5. Concerning
158 deployment, this document targets a wide audience, namely all
159 deployers who wish to add authentication (be it one-way only or
160 mutual), confidentiality, and data integrity protection to their
163 The recommendations herein take into consideration the security of
164 various mechanisms, their technical maturity and interoperability,
165 and their prevalence in implementations at the time of writing.
166 Unless it is explicitly called out that a recommendation applies to
167 TLS alone or to DTLS alone, each recommendation applies to both TLS
170 This document attempts to minimize new guidance to TLS 1.2
171 implementations, and the overall approach is to encourage systems to
172 move to TLS 1.3. However, this is not always practical. Newly
173 discovered attacks, as well as ecosystem changes, necessitated some
174 new requirements that apply to TLS 1.2 environments. Those are
175 summarized in Appendix A.
177 Naturally, future attacks are likely, and this document cannot
178 address them. Those who implement and deploy TLS/DTLS and protocols
179 based on TLS/DTLS are strongly advised to pay attention to future
180 developments. In particular, although it is known that the creation
181 of quantum computers will have a significant impact on the security
182 of cryptographic primitives and the technologies that use them,
183 currently post-quantum cryptography is a work in progress and it is
184 too early to make recommendations; once the relevant specifications
185 are standardized in the IETF or elsewhere, this document should be
186 updated to reflect best practices at that time.
188 As noted, the TLS 1.3 specification resolves many of the
189 vulnerabilities listed in this document. A system that deploys TLS
190 1.3 should have fewer vulnerabilities than TLS 1.2 or below.
191 Therefore, this document replaces [RFC7525], with an explicit goal to
192 encourage migration of most uses of TLS 1.2 to TLS 1.3.
194 These are minimum recommendations for the use of TLS in the vast
195 majority of implementation and deployment scenarios, with the
196 exception of unauthenticated TLS (see Section 5). Other
197 specifications that reference this document can have stricter
198 requirements related to one or more aspects of the protocol, based on
199 their particular circumstances (e.g., for use with a specific
200 application protocol); when that is the case, implementers are
201 advised to adhere to those stricter requirements. Furthermore, this
202 document provides a floor, not a ceiling: where feasible,
203 administrators of services are encouraged to go beyond the minimum
204 support available in implementations to provide the strongest
205 security possible. For example, based on knowledge about the
206 deployed base for an existing application protocol and a cost-benefit
207 analysis regarding security strength vs. interoperability, a given
208 service provider might decide to disable TLS 1.2 entirely and offer
211 Community knowledge about the strength of various algorithms and
212 feasible attacks can change quickly, and experience shows that a Best
213 Current Practice (BCP) document about security is a point-in-time
214 statement. Readers are advised to seek out any errata or updates
215 that apply to this document.
217 This document updates [RFC5288] in view of the [Boeck2016] attack.
218 See Section 7.2.1 for the details.
220 This document updates [RFC6066] in view of the [ALPACA] attack. See
221 Section 3.7 for the details.
225 A number of security-related terms in this document are used in the
226 sense defined in [RFC4949], including "attack", "authentication",
227 "certificate", "cipher", "compromise", "confidentiality",
228 "credential", "data integrity", "encryption", "forward secrecy",
229 "key", "key length", "self-signed certificate", "strength", and
232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
234 "OPTIONAL" in this document are to be interpreted as described in
235 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
236 capitals, as shown here.
2383. General Recommendations
240 This section provides general recommendations on the secure use of
241 TLS. Recommendations related to cipher suites are discussed in the
2443.1. Protocol Versions
2463.1.1. SSL/TLS Protocol Versions
248 It is important both to stop using old, less secure versions of SSL/
249 TLS and to start using modern, more secure versions; therefore, the
250 following are the recommendations concerning TLS/SSL protocol
253 * Implementations MUST NOT negotiate SSL version 2.
255 Rationale: Today, SSLv2 is considered insecure [RFC6176].
257 * Implementations MUST NOT negotiate SSL version 3.
259 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and
260 plugged some significant security holes but did not support strong
261 cipher suites. SSLv3 does not support TLS extensions, some of
262 which (e.g., renegotiation_info [RFC5746]) are security critical.
263 In addition, with the emergence of the Padding Oracle On
264 Downgraded Legacy Encryption (POODLE) attack [POODLE], SSLv3 is
265 now widely recognized as fundamentally insecure. See [RFC7568]
268 * Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].
270 Rationale: TLS 1.0 (published in 1999) does not support many
271 modern, strong cipher suites. In addition, TLS 1.0 lacks a per-
272 record Initialization Vector (IV) for cipher suites based on
273 cipher block chaining (CBC) and does not warn against common
274 padding errors. This and other recommendations in this section
275 are in line with [RFC8996].
277 * Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].
279 Rationale: TLS 1.1 (published in 2006) is a security improvement
280 over TLS 1.0 but still does not support certain stronger cipher
281 suites that were introduced with the standardization of TLS 1.2 in
282 2008, including the cipher suites recommended for TLS 1.2 by this
283 document (see Section 4.2 below).
285 * Implementations MUST support TLS 1.2 [RFC5246].
287 Rationale: TLS 1.2 is implemented and deployed more widely than
288 TLS 1.3 at this time, and when the recommendations in this
289 document are followed to mitigate known attacks, the use of TLS
290 1.2 is as safe as the use of TLS 1.3. In most application
291 protocols that reuse TLS and DTLS, there is no immediate need to
292 migrate solely to TLS 1.3. Indeed, because many application
293 clients are dependent on TLS libraries or operating systems that
294 do not yet support TLS 1.3, proactively deprecating TLS 1.2 would
295 introduce significant interoperability issues, thus harming
296 security more than helping it. Nevertheless, it is expected that
297 a future version of this BCP will deprecate the use of TLS 1.2
298 when it is appropriate to do so.
300 * Implementations SHOULD support TLS 1.3 [RFC8446] and, if
301 implemented, MUST prefer to negotiate TLS 1.3 over earlier
304 Rationale: TLS 1.3 is a major overhaul to the protocol and
305 resolves many of the security issues with TLS 1.2. To the extent
306 that an implementation supports TLS 1.2 (even if it defaults to
307 TLS 1.3), it MUST follow the recommendations regarding TLS 1.2
308 specified in this document.
310 * New transport protocols that integrate the TLS/DTLS handshake
311 protocol and/or record layer MUST use only TLS/DTLS 1.3 (for
312 instance, QUIC [RFC9001] took this approach). New application
313 protocols that employ TLS/DTLS for channel or session encryption
314 MUST integrate with both TLS/DTLS versions 1.2 and 1.3;
315 nevertheless, in rare cases where broad interoperability is not a
316 concern, application protocol designers MAY choose to forego TLS
319 Rationale: Secure deployment of TLS 1.3 is significantly easier
320 and less error prone than secure deployment of TLS 1.2. When
321 designing a new secure transport protocol such as QUIC, there is
322 no reason to support TLS 1.2. By contrast, new application
323 protocols that reuse TLS need to support both TLS 1.3 and TLS 1.2
324 in order to take advantage of underlying library or operating
325 system support for both versions.
327 This BCP applies to TLS 1.3, TLS 1.2, and earlier versions. It is
328 not safe for readers to assume that the recommendations in this BCP
329 apply to any future version of TLS.
3313.1.2. DTLS Protocol Versions
333 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS
334 1.1 was published. The following are the recommendations with
337 * Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].
339 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
341 * Implementations MUST support DTLS 1.2 [RFC6347].
343 Version 1.2 of DTLS correlates to version 1.2 of TLS (see above).
344 (There is no version 1.1 of DTLS.)
346 * Implementations SHOULD support DTLS 1.3 [RFC9147] and, if
347 implemented, MUST prefer to negotiate DTLS version 1.3 over
348 earlier versions of DTLS.
350 Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).
3523.1.3. Fallback to Lower Versions
354 TLS/DTLS 1.2 clients MUST NOT fall back to earlier TLS versions,
355 since those versions have been deprecated [RFC8996]. As a result,
356 the downgrade-protection Signaling Cipher Suite Value (SCSV)
357 mechanism [RFC7507] is no longer needed for clients. In addition,
358 TLS 1.3 implements a new version-negotiation mechanism.
362 The following recommendations are provided to help prevent "SSL
363 Stripping" and STARTTLS command injection (attacks that are
364 summarized in [RFC7457]):
366 * Many existing application protocols were designed before the use
367 of TLS became common. These protocols typically support TLS in
368 one of two ways: either via a separate port for TLS-only
369 communication (e.g., port 443 for HTTPS) or via a method for
370 dynamically upgrading a channel from unencrypted to TLS protected
371 (e.g., STARTTLS, which is used in protocols such as IMAP and
372 XMPP). Regardless of the mechanism for protecting the
373 communication channel (TLS-only port or dynamic upgrade), what
374 matters is the end state of the channel. When a protocol defines
375 both a dynamic upgrade method and a separate TLS-only method, then
376 the separate TLS-only method MUST be supported by implementations
377 and MUST be configured by administrators to be used in preference
378 to the dynamic upgrade method. When a protocol supports only a
379 dynamic upgrade method, implementations MUST provide a way for
380 administrators to set a strict local policy that forbids use of
381 plaintext in the absence of a negotiated TLS channel, and
382 administrators MUST use this policy.
384 * HTTP client and server implementations intended for use in the
385 World Wide Web (see Section 5) MUST support the HTTP Strict
386 Transport Security (HSTS) header field [RFC6797] so that web
387 servers can advertise that they are willing to accept TLS-only
388 clients. Web servers SHOULD use HSTS to indicate that they are
389 willing to accept TLS-only clients, unless they are deployed in
390 such a way that using HSTS would in fact weaken overall security
391 (e.g., it can be problematic to use HSTS with self-signed
392 certificates, as described in Section 11.3 of [RFC6797]). Similar
393 technologies exist for non-HTTP application protocols, such as
394 Mail Transfer Agent Strict Transport Security (MTA-STS) for mail
395 transfer agents [RFC8461] and methods based on DNS-Based
396 Authentication of Named Entities (DANE) [RFC6698] for SMTP
397 [RFC7672] and XMPP [RFC7712].
399 Rationale: Combining unprotected and TLS-protected communication
400 opens the way to SSL Stripping and similar attacks, since an initial
401 part of the communication is not integrity protected and therefore
402 can be manipulated by an attacker whose goal is to keep the
403 communication in the clear.
407 In order to help prevent compression-related attacks (summarized in
408 Section 2.6 of [RFC7457]) when using TLS 1.2, implementations and
409 deployments SHOULD NOT support TLS-level compression (Section 6.2.2
410 of [RFC5246]); the only exception is when the application protocol in
411 question has been proven not to be open to such attacks. However,
412 even in this case, extreme caution is warranted because of the
413 potential for future attacks related to TLS compression. More
414 specifically, the HTTP protocol is known to be vulnerable to
415 compression-related attacks. (This recommendation applies to TLS 1.2
416 only, because compression has been removed from TLS 1.3.)
418 Rationale: TLS compression has been subject to security attacks such
419 as the Compression Ratio Info-leak Made Easy (CRIME) attack.
421 Implementers should note that compression at higher protocol levels
422 can allow an active attacker to extract cleartext information from
423 the connection. The Browser Reconnaissance and Exfiltration via
424 Adaptive Compression of Hypertext (BREACH) attack is one such case.
425 These issues can only be mitigated outside of TLS and are thus
426 outside the scope of this document. See Section 2.6 of [RFC7457] for
4293.3.1. Certificate Compression
431 Certificate chains often take up most of the bytes transmitted during
432 the handshake. In order to manage their size, some or all of the
433 following methods can be employed (see also Section 4 of [RFC9191]
434 for further suggestions):
436 * Limit the number of names or extensions.
438 * Use keys with small public key representations, like the Elliptic
439 Curve Digital Signature Algorithm (ECDSA).
441 * Use certificate compression.
443 To achieve the latter, TLS 1.3 defines the compress_certificate
444 extension in [RFC8879]. See also Section 5 of [RFC8879] for security
445 and privacy considerations associated with its use. For the
446 avoidance of doubt, CRIME-style attacks on TLS compression do not
447 apply to certificate compression.
449 Due to the strong likelihood of middlebox interference, compression
450 in the style of [RFC8879] has not been made available in TLS 1.2. In
451 theory, the cached_info extension defined in [RFC7924] could be used,
452 but it is not supported widely enough to be considered a practical
4553.4. TLS Session Resumption
457 Session resumption drastically reduces the number of full TLS
458 handshakes and thus is an essential performance feature for most
461 Stateless session resumption with session tickets is a popular
462 strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, a
463 more secure mechanism based on the use of a pre-shared key (PSK) is
464 described in Section 4.6.1 of [RFC8446]. See [Springall16] for a
465 quantitative study of the risks induced by TLS cryptographic
466 "shortcuts", including session resumption.
468 When it is used, the resumption information MUST be authenticated and
469 encrypted to prevent modification or eavesdropping by an attacker.
470 Further recommendations apply to session tickets:
472 * A strong cipher MUST be used when encrypting the ticket (at least
473 as strong as the main TLS cipher suite).
475 * Ticket-encryption keys MUST be changed regularly, e.g., once every
476 week, so as not to negate the benefits of forward secrecy (see
477 Section 7.3 for details on forward secrecy). Old ticket-
478 encryption keys MUST be destroyed at the end of the validity
481 * For similar reasons, session ticket validity MUST be limited to a
482 reasonable duration (e.g., half as long as ticket-encryption key
485 * TLS 1.2 does not roll the session key forward within a single
486 session. Thus, to prevent an attack where the server's ticket-
487 encryption key is stolen and used to decrypt the entire content of
488 a session (negating the concept of forward secrecy), a TLS 1.2
489 server SHOULD NOT resume sessions that are too old, e.g., sessions
490 that have been open longer than two ticket-encryption key rotation
493 Rationale: Session resumption is another kind of TLS handshake and
494 therefore must be as secure as the initial handshake. This document
495 (Section 4) recommends the use of cipher suites that provide forward
496 secrecy, i.e., that prevent an attacker who gains momentary access to
497 the TLS endpoint (either client or server) and its secrets from
498 reading either past or future communication. The tickets must be
499 managed so as not to negate this security property.
501 TLS 1.3 provides the powerful option of forward secrecy even within a
502 long-lived connection that is periodically resumed. Section 2.2 of
503 [RFC8446] recommends that clients SHOULD send a "key_share" when
504 initiating session resumption. In order to gain forward secrecy,
505 this document recommends that server implementations SHOULD select
506 the "psk_dhe_ke" PSK key exchange mode and respond with a "key_share"
507 to complete an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
508 exchange on each session resumption. As a more performant
509 alternative, server implementations MAY refrain from responding with
510 a "key_share" until a certain amount of time (e.g., measured in
511 hours) has passed since the last ECDHE exchange; this implies that
512 the "key_share" operation would not occur for the presumed majority
513 of session resumption requests (which would occur within a few hours)
514 while still ensuring forward secrecy for longer-lived sessions.
516 TLS session resumption introduces potential privacy issues where the
517 server is able to track the client, in some cases indefinitely. See
518 [Sy2018] for more details.
5203.5. Renegotiation in TLS 1.2
522 The recommendations in this section apply to TLS 1.2 only, because
523 renegotiation has been removed from TLS 1.3.
525 Renegotiation in TLS 1.2 is a handshake that establishes new
526 cryptographic parameters for an existing session. The mechanism
527 existed in TLS 1.2 and in earlier protocol versions and was improved
528 following several major attacks including a plaintext injection
529 attack, CVE-2009-3555 [CVE].
531 TLS 1.2 clients and servers MUST implement the renegotiation_info
532 extension, as defined in [RFC5746].
534 TLS 1.2 clients MUST send renegotiation_info in the Client Hello. If
535 the server does not acknowledge the extension, the client MUST
536 generate a fatal handshake_failure alert prior to terminating the
539 Rationale: It is not safe for a client to connect to a TLS 1.2 server
540 that does not support renegotiation_info regardless of whether either
541 endpoint actually implements renegotiation. See also Section 4.1 of
544 A related attack resulting from TLS session parameters not being
545 properly authenticated is a Triple Handshake [Triple-Handshake]. To
546 address this attack, TLS 1.2 implementations MUST support the
547 extended_master_secret extension defined in [RFC7627].
5493.6. Post-Handshake Authentication
551 Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by
552 separate post-handshake authentication and key update mechanisms. In
553 the context of protocols that multiplex requests over a single
554 connection (such as HTTP/2 [RFC9113]), post-handshake authentication
555 has the same problems as TLS 1.2 renegotiation. Multiplexed
556 protocols SHOULD follow the advice provided for HTTP/2 in
557 Section 9.2.3 of [RFC9113].
5593.7. Server Name Indication (SNI)
561 TLS implementations MUST support the Server Name Indication (SNI)
562 extension defined in Section 3 of [RFC6066] for those higher-level
563 protocols that would benefit from it, including HTTPS. However, the
564 actual use of SNI in particular circumstances is a matter of local
565 policy. At the time of writing, a technology for encrypting the SNI
566 (called Encrypted Client Hello) is being worked on in the TLS Working
567 Group [TLS-ECH]. Once that method has been standardized and widely
568 implemented, it will likely be appropriate to recommend its usage in
569 a future version of this BCP.
571 Rationale: SNI supports deployment of multiple TLS-protected virtual
572 servers on a single address, and therefore enables fine-grained
573 security for these virtual servers, by allowing each one to have its
574 own certificate. However, SNI also leaks the target domain for a
575 given connection; this information leak will be closed by use of TLS
576 Encrypted Client Hello once that method has been standardized.
579 does not recognize the presented server name SHOULD NOT continue the
580 handshake and instead SHOULD fail with a fatal-level
581 unrecognized_name(112) alert. Note that this recommendation updates
582 Section 3 of [RFC6066], which stated:
584 | If the server understood the ClientHello extension but does not
585 | recognize the server name, the server SHOULD take one of two
586 | actions: either abort the handshake by sending a fatal-level
587 | unrecognized_name(112) alert or continue the handshake.
590 extension but presents a certificate with a different hostname than
591 the one sent by the client.
5933.8. Application-Layer Protocol Negotiation (ALPN)
595 TLS implementations (both client- and server-side) MUST support the
596 Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].
598 In order to prevent "cross-protocol" attacks resulting from failure
599 to ensure that a message intended for use in one protocol cannot be
600 mistaken for a message for use in another protocol, servers are
601 advised to strictly enforce the behavior prescribed in Section 3.2 of
604 | In the event that the server supports no protocols that the client
605 | advertises, then the server SHALL respond with a fatal
606 | 'no_application_protocol' alert.
608 Clients SHOULD abort the handshake if the server acknowledges the
609 ALPN extension but does not select a protocol from the client list.
610 Failure to do so can result in attacks such those described in
613 Protocol developers are strongly encouraged to register an ALPN
614 identifier for their protocols. This applies both to new protocols
615 and to well-established protocols; however, because the latter might
616 have a large deployed base, strict enforcement of ALPN usage may not
617 be feasible when an ALPN identifier is registered for a well-
618 established protocol.
6203.9. Multi-Server Deployment
622 Deployments that involve multiple servers or services can increase
623 the size of the attack surface for TLS. Two scenarios are of
626 1. Deployments in which multiple services handle the same domain
627 name via different protocols (e.g., HTTP and IMAP). In this
628 case, an attacker might be able to direct a connecting endpoint
629 to the service offering a different protocol and mount a cross-
630 protocol attack. In a cross-protocol attack, the client and
631 server believe they are using different protocols, which the
632 attacker might exploit if messages sent in one protocol are
633 interpreted as messages in the other protocol with undesirable
634 effects (see [ALPACA] for more detailed information about this
635 class of attacks). To mitigate this threat, service providers
636 SHOULD deploy ALPN (see Section 3.8). In addition, to the extent
637 possible, they SHOULD ensure that multiple services handling the
638 same domain name provide equivalent levels of security that are
639 consistent with the recommendations in this document; such
640 measures SHOULD include the handling of configurations across
641 multiple TLS servers and protections against compromise of
642 credentials held by those servers.
644 2. Deployments in which multiple servers providing the same service
645 have different TLS configurations. In this case, an attacker
646 might be able to direct a connecting endpoint to a server with a
647 TLS configuration that is more easily exploitable (see [DROWN]
648 for more detailed information about this class of attacks). To
649 mitigate this threat, service providers SHOULD ensure that all
650 servers providing the same service provide equivalent levels of
651 security that are consistent with the recommendations in this
6543.10. Zero Round-Trip Time (0-RTT) Data in TLS 1.3
656 The 0-RTT early data feature is new in TLS 1.3. It provides reduced
657 latency when TLS connections are resumed, at the potential cost of
658 certain security properties. As a result, it requires special
659 attention from implementers on both the server and the client side.
660 Typically, this extends to the TLS library as well as protocol layers
663 For HTTP over TLS, refer to [RFC8470] for guidance.
665 For QUIC on TLS, refer to Section 9.2 of [RFC9001].
667 For other protocols, generic guidance is given in Section 8 and
668 Appendix E.5 of [RFC8446]. To paraphrase Appendix E.5, applications
669 MUST avoid this feature unless an explicit specification exists for
670 the application protocol in question to clarify when 0-RTT is
671 appropriate and secure. This can take the form of an IETF RFC, a
672 non-IETF standard, or documentation associated with a non-standard
6754. Recommendations: Cipher Suites
677 TLS 1.2 provided considerable flexibility in the selection of cipher
678 suites. Unfortunately, the security of some of these cipher suites
679 has degraded over time to the point where some are known to be
680 insecure (this is one reason why TLS 1.3 restricted such
681 flexibility). Incorrectly configuring a server leads to no or
682 reduced security. This section includes recommendations on the
683 selection and negotiation of cipher suites.
6854.1. General Guidelines
687 Cryptographic algorithms weaken over time as cryptanalysis improves:
688 algorithms that were once considered strong become weak.
689 Consequently, cipher suites using weak algorithms need to be phased
690 out and replaced with more secure cipher suites. This helps to
691 ensure that the desired security properties still hold. SSL/TLS has
692 been in existence for well over 20 years and many of the cipher
693 suites that have been recommended in various versions of SSL/TLS are
694 now considered weak or at least not as strong as desired. Therefore,
695 this section modernizes the recommendations concerning cipher suite
698 * Implementations MUST NOT negotiate the cipher suites with NULL
701 Rationale: The NULL cipher suites do not encrypt traffic and so
702 provide no confidentiality services. Any entity in the network
703 with access to the connection can view the plaintext of contents
704 being exchanged by the client and server. Nevertheless, this
705 document does not discourage software from implementing NULL
706 cipher suites, since they can be useful for testing and debugging.
708 * Implementations MUST NOT negotiate RC4 cipher suites.
710 Rationale: The RC4 stream cipher has a variety of cryptographic
711 weaknesses, as documented in [RFC7465]. Note that DTLS
712 specifically forbids the use of RC4 already.
714 * Implementations MUST NOT negotiate cipher suites offering less
715 than 112 bits of security, including so-called "export-level"
716 encryption (which provides 40 or 56 bits of security).
718 Rationale: Based on [RFC3766], at least 112 bits of security is
719 needed. 40-bit and 56-bit security (found in so-called "export
720 ciphers") are considered insecure today.
722 * Implementations SHOULD NOT negotiate cipher suites that use
723 algorithms offering less than 128 bits of security.
725 Rationale: Cipher suites that offer 112 or more bits but less than
726 128 bits of security are not considered weak at this time;
727 however, it is expected that their useful lifespan is short enough
728 to justify supporting stronger cipher suites at this time.
729 128-bit ciphers are expected to remain secure for at least several
730 years and 256-bit ciphers until the next fundamental technology
731 breakthrough. Note that, because of so-called "meet-in-the-
732 middle" attacks [Multiple-Encryption], some legacy cipher suites
733 (e.g., 168-bit Triple DES (3DES)) have an effective key length
734 that is smaller than their nominal key length (112 bits in the
735 case of 3DES). Such cipher suites should be evaluated according
736 to their effective key length.
738 * Implementations SHOULD NOT negotiate cipher suites based on RSA
739 key transport, a.k.a. "static RSA".
741 Rationale: These cipher suites, which have assigned values
742 starting with the string "TLS_RSA_WITH_*", have several drawbacks,
743 especially the fact that they do not support forward secrecy.
745 * Implementations SHOULD NOT negotiate cipher suites based on non-
746 ephemeral (static) finite-field Diffie-Hellman (DH) key agreement.
747 Similarly, implementations SHOULD NOT negotiate non-ephemeral
748 Elliptic Curve DH key agreement.
750 Rationale: The former cipher suites, which have assigned values
751 prefixed by "TLS_DH_*", have several drawbacks, especially the
752 fact that they do not support forward secrecy. The latter
753 ("TLS_ECDH_*") also lack forward secrecy and are subject to
754 invalid curve attacks [Jager2015].
756 * Implementations MUST support and prefer to negotiate cipher suites
757 offering forward secrecy. However, TLS 1.2 implementations SHOULD
758 NOT negotiate cipher suites based on ephemeral finite-field
759 Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites). This is
760 justified by the known fragility of the construction (see
761 [RACCOON]) and the limitation around negotiation, including using
762 [RFC7919], which has seen very limited uptake.
764 Rationale: Forward secrecy (sometimes called "perfect forward
765 secrecy") prevents the recovery of information that was encrypted
766 with older session keys, thus limiting how far back in time data
767 can be decrypted when an attack is successful. See Sections 7.3
768 and 7.4 for a detailed discussion.
7704.2. Cipher Suites for TLS 1.2
772 Given the foregoing considerations, implementation and deployment of
773 the following cipher suites is RECOMMENDED:
775 * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
777 * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
779 * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
781 * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
783 As these are Authenticated Encryption with Associated Data (AEAD)
784 algorithms [RFC5116], these cipher suites are supported only in TLS
785 1.2 and not in earlier protocol versions.
787 Typically, to prefer these suites, the order of suites needs to be
788 explicitly configured in server software. It would be ideal if
789 server software implementations were to prefer these suites by
792 Some devices have hardware support for AES Counter Mode with CBC-MAC
793 (AES-CCM) but not AES Galois/Counter Mode (AES-GCM), so they are
794 unable to follow the foregoing recommendations regarding cipher
795 suites. There are even devices that do not support public key
796 cryptography at all, but these are out of scope entirely.
798 A cipher suite that operates in CBC (cipher block chaining) mode
799 (e.g., TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) SHOULD NOT be used
800 unless the encrypt_then_mac extension [RFC7366] is also successfully
801 negotiated. This requirement applies to both client and server
804 When using ECDSA signatures for authentication of TLS peers, it is
805 RECOMMENDED that implementations use the NIST curve P-256. In
806 addition, to avoid predictable or repeated nonces (which could reveal
807 the long-term signing key), it is RECOMMENDED that implementations
808 implement "deterministic ECDSA" as specified in [RFC6979] and in line
809 with the recommendations in [RFC8446].
811 Note that implementations of "deterministic ECDSA" may be vulnerable
812 to certain side-channel and fault injection attacks precisely because
813 of their determinism. While most fault injection attacks described
814 in the literature assume physical access to the device (and therefore
815 are more relevant in Internet of Things (IoT) deployments with poor
816 or non-existent physical security), some can be carried out remotely
817 [Poddebniak2017], e.g., as Rowhammer [Kim2014] variants. In
818 deployments where side-channel attacks and fault injection attacks
819 are a concern, implementation strategies combining both randomness
820 and determinism (for example, as described in [CFRG-DET-SIGS]) can be
821 used to avoid the risk of successful extraction of the signing key.
8234.2.1. Implementation Details
825 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the
826 first proposal to any server. Servers MUST prefer this cipher suite
827 over weaker cipher suites whenever it is proposed, even if it is not
828 the first proposal. Clients are of course free to offer stronger
829 cipher suites, e.g., using AES-256; when they do, the server SHOULD
830 prefer the stronger cipher suite unless there are compelling reasons
831 (e.g., seriously degraded performance) to choose otherwise.
833 The previous version of the TLS recommendations [RFC7525] implicitly
834 allowed the old RFC 5246 mandatory-to-implement cipher suite,
835 TLS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher
836 suite does not provide additional interoperability, except with very
837 old clients. As with other cipher suites that do not provide forward
838 secrecy, implementations SHOULD NOT support this cipher suite. Other
839 application protocols specify other cipher suites as mandatory to
842 [RFC8422] allows clients and servers to negotiate ECDH parameters
843 (curves). Both clients and servers SHOULD include the "Supported
844 Elliptic Curves Extension" [RFC8422]. Clients and servers SHOULD
845 support the NIST P-256 (secp256r1) [RFC8422] and X25519 (x25519)
846 [RFC7748] curves. Note that [RFC8422] deprecates all but the
847 uncompressed point format. Therefore, if the client sends an
848 ec_point_formats extension, the ECPointFormatList MUST contain a
849 single element, "uncompressed".
8514.3. Cipher Suites for TLS 1.3
853 This document does not specify any cipher suites for TLS 1.3.
854 Readers are referred to Section 9.1 of [RFC8446] for cipher suite
8574.4. Limits on Key Usage
859 All ciphers have an upper limit on the amount of traffic that can be
860 securely protected with any given key. In the case of AEAD cipher
861 suites, two separate limits are maintained for each key:
863 1. Confidentiality limit (CL), i.e., the number of records that can
866 2. Integrity limit (IL), i.e., the number of records that are
867 allowed to fail authentication.
869 The latter applies to DTLS (and also to QUIC) but not to TLS itself,
870 since TLS connections are torn down on the first decryption failure.
872 When a sender is approaching CL, the implementation SHOULD initiate a
873 new handshake (in TLS 1.3, this can be achieved by sending a
874 KeyUpdate message on the established session) to rotate the session
875 key. When a receiver has reached IL, the implementation SHOULD close
876 the connection. Although these recommendations are a best practice,
877 implementers need to be aware that it is not always easy to
878 accomplish them in protocols that are built on top of TLS/DTLS
879 without introducing coordination across layer boundaries. See
880 Section 6 of [RFC9001] for an example of the cooperation that was
881 necessary in QUIC between the crypto and transport layers to support
882 key updates. Note that in general, application protocols might not
883 be able to emulate that method given their more constrained
884 interaction with TLS/DTLS. As a result of these complexities, these
885 recommendations are not mandatory.
887 For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of
888 [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher
889 suites, readers are referred to Section 4.5.3 of [RFC9147].
891 For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in
892 this document, CL can be derived by plugging the corresponding
893 parameters into the inequalities in Section 6.1 of [AEAD-LIMITS] that
894 apply to random, partially implicit nonces, i.e., the nonce
895 construction used in TLS 1.2. Although the obtained figures are
896 slightly higher than those for TLS 1.3, it is RECOMMENDED that the
897 same limit of 2^24.5 records is used for both versions.
899 For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained
900 from the same inequalities referenced above) is 2^28.
9024.5. Public Key Length
904 When using the cipher suites recommended in this document, two public
905 keys are normally used in the TLS handshake: one for the Diffie-
906 Hellman key agreement and one for server authentication. Where a
907 client certificate is used, a third public key is added.
909 With a key exchange based on modular exponential (MODP) Diffie-
910 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048
913 Rationale: For various reasons, in practice, DH keys are typically
914 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits,
915 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits
916 would be roughly equivalent to only an 80-bit symmetric key
917 [RFC3766], it is better to use keys longer than that for the "DHE"
918 family of cipher suites. A DH key of 1926 bits would be roughly
919 equivalent to a 100-bit symmetric key [RFC3766]. A DH key of 2048
920 bits (equivalent to a 112-bit symmetric key) is the minimum allowed
921 by the latest revision of [NIST.SP.800-56A] as of this writing (see
922 in particular Appendix D of that document).
924 As noted in [RFC3766], correcting for the emergence of The Weizmann
925 Institute Relation Locator (TWIRL) machine [TWIRL] would imply that
926 1024-bit DH keys yield about 61 bits of equivalent strength and that
927 a 2048-bit DH key would yield about 92 bits of equivalent strength.
928 The Logjam attack [Logjam] further demonstrates that 1024-bit Diffie-
929 Hellman parameters should be avoided.
931 With regard to ECDH keys, implementers are referred to the IANA "TLS
932 Supported Groups" registry (formerly known as the "EC Named Curve
933 Registry") within the "Transport Layer Security (TLS) Parameters"
934 registry [IANA_TLS] and in particular to the "recommended" groups.
935 Curves of less than 224 bits MUST NOT be used. This recommendation
936 is in line with the latest revision of [NIST.SP.800-56A].
938 When using RSA, servers MUST authenticate using certificates with at
939 least a 2048-bit modulus for the public key. In addition, the use of
940 the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST NOT
941 be used [RFC9155] (for more details, see also [CAB-Baseline], for
942 which the current version at the time of writing is 1.8.4). Clients
943 MUST indicate to servers that they request SHA-256 by using the
944 "Signature Algorithms" extension defined in TLS 1.2. For TLS 1.3,
945 the same requirement is already specified by [RFC8446].
950 Implementations MUST NOT use the Truncated HMAC Extension, defined in
951 Section 7 of [RFC6066].
953 Rationale: The extension does not apply to the AEAD cipher suites
954 recommended above. However, it does apply to most other TLS cipher
955 suites. Its use has been shown to be insecure in [PatersonRS11].
9575. Applicability Statement
959 The recommendations of this document primarily apply to the
960 implementation and deployment of application protocols that are most
961 commonly used with TLS and DTLS on the Internet today. Examples
962 include, but are not limited to:
964 * Web software and services that wish to protect HTTP traffic with
967 * Email software and services that wish to protect IMAP, Post Office
968 Protocol version 3 (POP3), or SMTP traffic with TLS.
970 * Instant-messaging software and services that wish to protect
971 Extensible Messaging and Presence Protocol (XMPP) or Internet
972 Relay Chat (IRC) traffic with TLS.
974 * Realtime media software and services that wish to protect Secure
975 Realtime Transport Protocol (SRTP) traffic with DTLS.
977 This document does not modify the implementation and deployment
978 recommendations (e.g., mandatory-to-implement cipher suites)
979 prescribed by existing application protocols that employ TLS or DTLS.
980 If the community that uses such an application protocol wishes to
981 modernize its usage of TLS or DTLS to be consistent with the best
982 practices recommended here, it needs to explicitly update the
983 existing application protocol definition (one example is [RFC7590],
984 which updates [RFC6120]).
986 Designers of new application protocols developed through the Internet
987 Standards Process [RFC2026] are expected at minimum to conform to the
988 best practices recommended here, unless they provide documentation of
989 compelling reasons that would prevent such conformance (e.g.,
990 widespread deployment on constrained devices that lack support for
991 the necessary algorithms).
993 Although many of the recommendations provided here might also apply
994 to QUIC insofar that it uses the TLS 1.3 handshake protocol, QUIC and
995 other such secure transport protocols are out of scope of this
996 document. For QUIC specifically, readers are referred to Section 9.2
999 This document does not address the use of TLS in constrained-node
1000 networks [RFC7228]. For recommendations regarding the profiling of
1001 TLS and DTLS for small devices with severe constraints on power,
1002 memory, and processing resources, the reader is referred to [RFC7925]
10055.1. Security Services
1007 This document provides recommendations for an audience that wishes to
1008 secure their communication with TLS to achieve the following:
1010 Confidentiality: all application-layer communication is encrypted
1011 with the goal that no party should be able to decrypt it except
1012 the intended receiver.
1014 Data integrity: any changes made to the communication in transit are
1015 detectable by the receiver.
1017 Authentication: an endpoint of the TLS communication is
1018 authenticated as the intended entity to communicate with.
1020 With regard to authentication, TLS enables authentication of one or
1021 both endpoints in the communication. In the context of opportunistic
1022 security [RFC7435], TLS is sometimes used without authentication. As
1023 discussed in Section 5.2, considerations for opportunistic security
1024 are not in scope for this document.
1026 If deployers deviate from the recommendations given in this document,
1027 they need to be aware that they might lose access to one of the
1028 foregoing security services.
1030 This document applies only to environments where confidentiality is
1031 required. It requires algorithms and configuration options that
1032 enforce secrecy of the data in transit.
1034 This document also assumes that data integrity protection is always
1035 one of the goals of a deployment. In cases where integrity is not
1036 required, it does not make sense to employ TLS in the first place.
1037 There are attacks against confidentiality-only protection that
1038 utilize the lack of integrity to also break confidentiality (see, for
1039 instance, [DegabrieleP07] in the context of IPsec).
1041 This document addresses itself to application protocols that are most
1042 commonly used on the Internet with TLS and DTLS. Typically, all
1043 communication between TLS clients and TLS servers requires all three
1044 of the above security services. This is particularly true where TLS
1045 clients are user agents like web browsers or email clients.
1047 This document does not address the rarer deployment scenarios where
1048 one of the above three properties is not desired, such as the use
1049 case described in Section 5.2. As another scenario where
1050 confidentiality is not needed, consider a monitored network where the
1051 authorities in charge of the respective traffic domain require full
1052 access to unencrypted (plaintext) traffic and where users collaborate
1053 and send their traffic in the clear.
10555.2. Opportunistic Security
1057 There are several important scenarios in which the use of TLS is
1058 optional, i.e., the client decides dynamically ("opportunistically")
1059 whether to use TLS with a particular server or to connect in the
1060 clear. This practice, often called "opportunistic security", is
1061 described at length in [RFC7435] and is often motivated by a desire
1062 for backward compatibility with legacy deployments.
1064 In these scenarios, some of the recommendations in this document
1065 might be too strict, since adhering to them could cause fallback to
1066 cleartext, a worse outcome than using TLS with an outdated protocol
1067 version or cipher suite.
10696. IANA Considerations
1071 This document has no IANA actions.
10737. Security Considerations
1075 This entire document discusses the security practices directly
1076 affecting applications using the TLS protocol. This section contains
1077 broader security considerations related to technologies used in
1078 conjunction with or by TLS. The reader is referred to the Security
1079 Considerations sections of TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], TLS
1080 1.2 [RFC5246], and DTLS 1.2 [RFC6347] for further context.
10827.1. Host Name Validation
1084 Application authors should take note that some TLS implementations do
1085 not validate host names. If the TLS implementation they are using
1086 does not validate host names, authors might need to write their own
1087 validation code or consider using a different TLS implementation.
1089 It is noted that the requirements regarding host name validation
1090 (and, in general, binding between the TLS layer and the protocol that
1091 runs above it) vary between different protocols. For HTTPS, these
1092 requirements are defined by Sections 4.3.3, 4.3.4, and 4.3.5 of
1095 Host name validation is security-critical for all common TLS use
1096 cases. Without it, TLS ensures that the certificate is valid and
1097 guarantees possession of the private key but does not ensure that the
1098 connection terminates at the desired endpoint. Readers are referred
1099 to [RFC6125] for further details regarding generic host name
1100 validation in the TLS context. In addition, that RFC contains a long
1101 list of application protocols, some of which implement a policy very
1102 different from HTTPS.
1104 If the host name is discovered indirectly and insecurely (e.g., by a
1105 cleartext DNS query for an SRV or Mail Exchange (MX) record), it
1106 SHOULD NOT be used as a reference identifier [RFC6125] even when it
1107 matches the presented certificate. This proviso does not apply if
1108 the host name is discovered securely (for further discussion, see
1109 [RFC7673] and [RFC7672]).
1111 Host name validation typically applies only to the leaf "end entity"
1112 certificate. Naturally, in order to ensure proper authentication in
1113 the context of the PKI, application clients need to verify the entire
1114 certification path in accordance with [RFC5280].
1118 Section 4.2 recommends the use of the AES-GCM authenticated
1119 encryption algorithm. Please refer to Section 6 of [RFC5288] for
1120 security considerations that apply specifically to AES-GCM when used
11237.2.1. Nonce Reuse in TLS 1.2
1125 The existence of deployed TLS stacks that mistakenly reuse the AES-
1126 GCM nonce is documented in [Boeck2016], showing there is an actual
1127 risk of AES-GCM getting implemented insecurely and thus making TLS
1128 sessions that use an AES-GCM cipher suite vulnerable to attacks such
1129 as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-2016-10213,
1130 CVE-2016-10212, and CVE-2017-5933.)
1132 While this problem has been fixed in TLS 1.3, which enforces a
1133 deterministic method to generate nonces from record sequence numbers
1134 and shared secrets for all its AEAD cipher suites (including AES-
1135 GCM), TLS 1.2 implementations could still choose their own
1136 (potentially insecure) nonce generation methods.
1138 It is therefore RECOMMENDED that TLS 1.2 implementations use the
1139 64-bit sequence number to populate the nonce_explicit part of the GCM
1140 nonce, as described in the first two paragraphs of Section 5.3 of
1141 [RFC8446]. This stronger recommendation updates Section 3 of
1142 [RFC5288], which specifies that the use of 64-bit sequence numbers to
1143 populate the nonce_explicit field is optional.
1145 We note that at the time of writing, there are no cipher suites
1146 defined for nonce-reuse-resistant algorithms such as AES-GCM-SIV
1151 Forward secrecy (also called "perfect forward secrecy" or "PFS" and
1152 defined in [RFC4949]) is a defense against an attacker who records
1153 encrypted conversations where the session keys are only encrypted
1154 with the communicating parties' long-term keys.
1156 Should the attacker be able to obtain these long-term keys at some
1157 point later in time, the session keys and thus the entire
1158 conversation could be decrypted.
1160 In the context of TLS and DTLS, such compromise of long-term keys is
1161 not entirely implausible. It can happen, for example, due to:
1163 * A client or server being attacked by some other attack vector, and
1164 the private key retrieved.
1166 * A long-term key retrieved from a device that has been sold or
1167 otherwise decommissioned without prior wiping.
1169 * A long-term key used on a device as a default key [Heninger2012].
1171 * A key generated by a trusted third party like a CA and later
1172 retrieved from it by either extortion or compromise
1175 * A cryptographic breakthrough or the use of asymmetric keys with
1176 insufficient length [Kleinjung2010].
1178 * Social engineering attacks against system administrators.
1180 * Collection of private keys from inadequately protected backups.
1182 Forward secrecy ensures in such cases that it is not feasible for an
1183 attacker to determine the session keys even if the attacker has
1184 obtained the long-term keys some time after the conversation. It
1185 also protects against an attacker who is in possession of the long-
1186 term keys but remains passive during the conversation.
1188 Forward secrecy is generally achieved by using the Diffie-Hellman
1189 scheme to derive session keys. The Diffie-Hellman scheme has both
1190 parties maintain private secrets and send parameters over the network
1191 as modular powers over certain cyclic groups. The properties of the
1192 so-called Discrete Logarithm Problem (DLP) allow the parties to
1193 derive the session keys without an eavesdropper being able to do so.
1194 There is currently no known attack against DLP if sufficiently large
1195 parameters are chosen. A variant of the Diffie-Hellman scheme uses
1196 elliptic curves instead of the originally proposed modular
1197 arithmetic. Given the current state of the art, Elliptic Curve
1198 Diffie-Hellman appears to be more efficient, permits shorter key
1199 lengths, and allows less freedom for implementation errors than
1200 finite-field Diffie-Hellman.
1202 Unfortunately, many TLS/DTLS cipher suites were defined that do not
1203 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This
1204 document therefore advocates strict use of forward-secrecy-only
12077.4. Diffie-Hellman Exponent Reuse
1209 For performance reasons, it is not uncommon for TLS implementations
1210 to reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents
1211 across multiple connections. Such reuse can result in major security
1214 * If exponents are reused for too long (in some cases, even as
1215 little as a few hours), an attacker who gains access to the host
1216 can decrypt previous connections. In other words, exponent reuse
1217 negates the effects of forward secrecy.
1219 * TLS implementations that reuse exponents should test the DH public
1220 key they receive for group membership, in order to avoid some
1221 known attacks. These tests are not standardized in TLS at the
1222 time of writing, although general guidance in this area is
1223 provided by [NIST.SP.800-56A] and available in many protocol
1226 * Under certain conditions, the use of static finite-field DH keys,
1227 or of ephemeral finite-field DH keys that are reused across
1228 multiple connections, can lead to timing attacks (such as those
1229 described in [RACCOON]) on the shared secrets used in Diffie-
1230 Hellman key exchange.
1232 * An "invalid curve" attack can be mounted against Elliptic Curve DH
1233 if the victim does not verify that the received point lies on the
1234 correct curve. If the victim is reusing the DH secrets, the
1235 attacker can repeat the probe varying the points to recover the
1236 full secret (see [Antipa2003] and [Jager2015]).
1238 To address these concerns:
1240 * TLS implementations SHOULD NOT use static finite-field DH keys and
1241 SHOULD NOT reuse ephemeral finite-field DH keys across multiple
1244 * Server implementations that want to reuse Elliptic Curve DH keys
1245 SHOULD either use a "safe curve" [SAFECURVES] (e.g., X25519) or
1246 perform the checks described in [NIST.SP.800-56A] on the received
12497.5. Certificate Revocation
1251 The following considerations and recommendations represent the
1252 current state of the art regarding certificate revocation, even
1253 though no complete and efficient solution exists for the problem of
1254 checking the revocation status of common public key certificates
1257 * Certificate revocation is an important tool when recovering from
1258 attacks on the TLS implementation as well as cases of misissued
1259 certificates. TLS implementations MUST implement a strategy to
1260 distrust revoked certificates.
1262 * Although Certificate Revocation Lists (CRLs) are the most widely
1263 supported mechanism for distributing revocation information, they
1264 have known scaling challenges that limit their usefulness, despite
1265 workarounds such as partitioned CRLs and delta CRLs. The more
1266 modern [CRLite] and the follow-on Let's Revoke [LetsRevoke] build
1267 on the availability of Certificate Transparency [RFC9162] logs and
1268 aggressive compression to allow practical use of the CRL
1269 infrastructure, but at the time of writing, neither solution is
1270 deployed for client-side revocation processing at scale.
1272 * Proprietary mechanisms that embed revocation lists in the web
1273 browser's configuration database cannot scale beyond the few most
1274 heavily used web servers.
1276 * The Online Certification Status Protocol (OCSP) [RFC6960] in its
1277 basic form presents both scaling and privacy issues. In addition,
1278 clients typically "soft-fail", meaning that they do not abort the
1279 TLS connection if the OCSP server does not respond. (However,
1280 this might be a workaround to avoid denial-of-service attacks if
1281 an OCSP responder is taken offline.) For a recent survey of the
1282 status of OCSP deployment in the web PKI, see [Chung18].
1284 * The TLS Certificate Status Request extension (Section 8 of
1285 [RFC6066]), commonly called "OCSP stapling", resolves the
1286 operational issues with OCSP. However, it is still ineffective in
1287 the presence of an active on-path attacker because the attacker
1288 can simply ignore the client's request for a stapled OCSP
1291 * [RFC7633] defines a certificate extension that indicates that
1292 clients must expect stapled OCSP responses for the certificate and
1293 must abort the handshake ("hard-fail") if such a response is not
1296 * OCSP stapling as used in TLS 1.2 does not extend to intermediate
1297 certificates within a certificate chain. The Multiple Certificate
1298 Status extension [RFC6961] addresses this shortcoming, but it has
1299 seen little deployment and had been deprecated by [RFC8446]. As a
1300 result, although this extension was recommended for TLS 1.2 in
1301 [RFC7525], it is no longer recommended by this document.
1303 * TLS 1.3 (Section 4.4.2.1 of [RFC8446]) allows the association of
1304 OCSP information with intermediate certificates by using an
1305 extension to the CertificateEntry structure. However, using this
1306 facility remains impractical because many certification
1307 authorities (CAs) either do not publish OCSP for CA certificates
1308 or publish OCSP reports with a lifetime that is too long to be
1311 * Both CRLs and OCSP depend on relatively reliable connectivity to
1312 the Internet, which might not be available to certain kinds of
1313 nodes. A common example is newly provisioned devices that need to
1314 establish a secure connection in order to boot up for the first
1317 For the common use cases of public key certificates in TLS, servers
1318 SHOULD support the following as a best practice given the current
1319 state of the art and as a foundation for a possible future solution:
1320 OCSP [RFC6960] and OCSP stapling using the status_request extension
1321 defined in [RFC6066]. Note that the exact mechanism for embedding
1322 the status_request extension differs between TLS 1.2 and 1.3. As a
1323 matter of local policy, server operators MAY request that CAs issue
1324 must-staple [RFC7633] certificates for the server and/or for client
1325 authentication, but we recommend reviewing the operational conditions
1326 before deciding on this approach.
1328 The considerations in this section do not apply to scenarios where
1329 the DNS-Based Authentication of Named Entities (DANE) TLSA resource
1330 record [RFC6698] is used to signal to a client which certificate a
1331 server considers valid and good to use for TLS connections.
13358.1. Normative References
1337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1338 Requirement Levels", BCP 14, RFC 2119,
1339 DOI 10.17487/RFC2119, March 1997,
1340 <https://www.rfc-editor.org/info/rfc2119>.
1342 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1343 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1344 RFC 3766, DOI 10.17487/RFC3766, April 2004,
1345 <https://www.rfc-editor.org/info/rfc3766>.
1347 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1348 (TLS) Protocol Version 1.2", RFC 5246,
1349 DOI 10.17487/RFC5246, August 2008,
1350 <https://www.rfc-editor.org/info/rfc5246>.
1352 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1353 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1354 DOI 10.17487/RFC5288, August 2008,
1355 <https://www.rfc-editor.org/info/rfc5288>.
1357 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
1358 "Transport Layer Security (TLS) Renegotiation Indication
1359 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
1360 <https://www.rfc-editor.org/info/rfc5746>.
1362 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1363 Extensions: Extension Definitions", RFC 6066,
1364 DOI 10.17487/RFC6066, January 2011,
1365 <https://www.rfc-editor.org/info/rfc6066>.
1367 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1368 Verification of Domain-Based Application Service Identity
1369 within Internet Public Key Infrastructure Using X.509
1370 (PKIX) Certificates in the Context of Transport Layer
1371 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
1372 2011, <https://www.rfc-editor.org/info/rfc6125>.
1374 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
1375 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
1376 2011, <https://www.rfc-editor.org/info/rfc6176>.
1378 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1379 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
1380 January 2012, <https://www.rfc-editor.org/info/rfc6347>.
1382 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
1383 Algorithm (DSA) and Elliptic Curve Digital Signature
1384 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
1385 2013, <https://www.rfc-editor.org/info/rfc6979>.
1387 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
1388 "Transport Layer Security (TLS) Application-Layer Protocol
1389 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
1390 July 2014, <https://www.rfc-editor.org/info/rfc7301>.
1392 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
1393 Security (TLS) and Datagram Transport Layer Security
1394 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014,
1395 <https://www.rfc-editor.org/info/rfc7366>.
1397 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
1398 DOI 10.17487/RFC7465, February 2015,
1399 <https://www.rfc-editor.org/info/rfc7465>.
1401 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
1402 Langley, A., and M. Ray, "Transport Layer Security (TLS)
1403 Session Hash and Extended Master Secret Extension",
1404 RFC 7627, DOI 10.17487/RFC7627, September 2015,
1405 <https://www.rfc-editor.org/info/rfc7627>.
1407 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
1408 for Security", RFC 7748, DOI 10.17487/RFC7748, January
1409 2016, <https://www.rfc-editor.org/info/rfc7748>.
1411 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1412 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1413 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1415 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
1416 Curve Cryptography (ECC) Cipher Suites for Transport Layer
1417 Security (TLS) Versions 1.2 and Earlier", RFC 8422,
1418 DOI 10.17487/RFC8422, August 2018,
1419 <https://www.rfc-editor.org/info/rfc8422>.
1421 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1422 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1423 <https://www.rfc-editor.org/info/rfc8446>.
1425 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1426 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
1427 <https://www.rfc-editor.org/info/rfc8996>.
1429 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
1430 Datagram Transport Layer Security (DTLS) Protocol Version
1431 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
1432 <https://www.rfc-editor.org/info/rfc9147>.
1434 [RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
1435 MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2",
1436 RFC 9155, DOI 10.17487/RFC9155, December 2021,
1437 <https://www.rfc-editor.org/info/rfc9155>.
14398.2. Informative References
1442 Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
1443 AEAD Algorithms", Work in Progress, Internet-Draft, draft-
1444 irtf-cfrg-aead-limits-05, 11 July 2022,
1445 <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
1448 [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D.,
1449 Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel,
1450 "ALPACA: Application Layer Protocol Confusion - Analyzing
1451 and Mitigating Cracks in TLS Authentication", 30th USENIX
1452 Security Symposium (USENIX Security 21), August 2021,
1453 <https://www.usenix.org/conference/usenixsecurity21/
1454 presentation/brinkmann>.
1457 Antipa, A., Brown, D. R. L., Menezes, A., Struik, R., and
1458 S. Vanstone, "Validation of Elliptic Curve Public Keys",
1459 Public Key Cryptography - PKC 2003, December 2003,
1460 <https://doi.org/10.1007/3-540-36288-6_16>.
1463 Böck, H., Zauner, A., Devlin, S., Somorovsky, J., and P.
1464 Jovanovic, "Nonce-Disrespecting Adversaries: Practical
1465 Forgery Attacks on GCM in TLS", May 2016,
1466 <https://eprint.iacr.org/2016/475.pdf>.
1469 CA/Browser Forum, "Baseline Requirements for the Issuance
1470 and Management of Publicly-Trusted Certificates",
1471 Version 1.8.4, April 2022,
1472 <https://cabforum.org/documents/>.
1475 Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa,
1476 "Deterministic ECDSA and EdDSA Signatures with Additional
1477 Randomness", Work in Progress, Internet-Draft, draft-irtf-
1478 cfrg-det-sigs-with-noise-00, 8 August 2022,
1479 <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
1480 det-sigs-with-noise-00>.
1482 [Chung18] Chung, T., Lok, J., Chandrasekaran, B., Choffnes, D.,
1483 Levin, D., Maggs, B., Mislove, A., Rula, J., Sullivan, N.,
1484 and C. Wilson, "Is the Web Ready for OCSP Must-Staple?",
1485 Proceedings of the Internet Measurement Conference 2018,
1486 DOI 10.1145/3278532.3278543, October 2018,
1487 <https://doi.org/10.1145/3278532.3278543>.
1489 [CRLite] Larisch, J., Choffnes, D., Levin, D., Maggs, B., Mislove,
1490 A., and C. Wilson, "CRLite: A Scalable System for Pushing
1491 All TLS Revocations to All Browsers", 2017 IEEE Symposium
1492 on Security and Privacy (SP), DOI 10.1109/sp.2017.17, May
1493 2017, <https://doi.org/10.1109/sp.2017.17>.
1495 [CVE] MITRE, "Common Vulnerabilities and Exposures",
1496 <https://cve.mitre.org>.
1499 Degabriele, J. and K. Paterson, "Attacking the IPsec
1500 Standards in Encryption-only Configurations", 2007 IEEE
1501 Symposium on Security and Privacy (SP '07),
1502 DOI 10.1109/sp.2007.8, May 2007,
1503 <https://doi.org/10.1109/sp.2007.8>.
1505 [DROWN] Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N.,
1506 Dankel, M., Steube, J., Valenta, L., Adrian, D.,
1507 Halderman, J., Dukhovni, V., Käsper, E., Cohney, S.,
1508 Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS
1509 using SSLv2", 25th USENIX Security Symposium (USENIX
1510 Security 16), August 2016,
1511 <https://www.usenix.org/conference/usenixsecurity16/
1512 technical-sessions/presentation/aviram>.
1515 Heninger, N., Durumeric, Z., Wustrow, E., and J. A.
1516 Halderman, "Mining Your Ps and Qs: Detection of Widespread
1517 Weak Keys in Network Devices", 21st Usenix Security
1518 Symposium, August 2012.
1520 [IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters",
1521 <https://www.iana.org/assignments/tls-parameters>.
1524 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for
1525 the Internet of Things", Work in Progress, Internet-Draft,
1526 draft-ietf-uta-tls13-iot-profile-05, 6 July 2022,
1527 <https://datatracker.ietf.org/doc/html/draft-ietf-uta-
1528 tls13-iot-profile-05>.
1531 Jager, T., Schwenk, J., and J. Somorovsky, "Practical
1532 Invalid Curve Attacks on TLS-ECDH", Computer Security --
1533 ESORICS 2015, pp. 407-425,
1534 DOI 10.1007/978-3-319-24174-6_21, 2015,
1535 <https://doi.org/10.1007/978-3-319-24174-6_21>.
1537 [Joux2006] Joux, A., "Authentication Failures in NIST version of
1538 GCM", 2006, <https://csrc.nist.gov/csrc/media/projects/
1539 block-cipher-techniques/documents/bcm/comments/800-38-
1540 series-drafts/gcm/joux_comments.pdf>.
1542 [Kim2014] Kim, Y., Daly, R., Kim, J., Fallin, C., Lee, J. H., Lee,
1543 D., Wilkerson, C., Lai, K., and O. Mutlu, "Flipping Bits
1544 in Memory Without Accessing Them: An Experimental Study of
1545 DRAM Disturbance Errors", DOI 10.1109/ISCA.2014.6853210,
1546 July 2014, <https://users.ece.cmu.edu/~yoonguk/papers/kim-
1550 Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé,
1551 E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P.,
1552 Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann,
1553 "Factorization of a 768-Bit RSA Modulus", Advances in
1554 Cryptology - CRYPTO 2010, pp. 333-350,
1555 DOI 10.1007/978-3-642-14623-7_18, 2010,
1556 <https://doi.org/10.1007/978-3-642-14623-7_18>.
1559 Smith, T., Dickinson, L., and K. Seamons, "Let's Revoke:
1560 Scalable Global Certificate Revocation", Proceedings 2020
1561 Network and Distributed System Security Symposium,
1562 DOI 10.14722/ndss.2020.24084, February 2020,
1563 <https://doi.org/10.14722/ndss.2020.24084>.
1565 [Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
1566 Green, M., Halderman, J., Heninger, N., Springall, D.,
1567 Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E.,
1568 Zanella-Béguelin, S., and P. Zimmermann, "Imperfect
1569 Forward Secrecy: How Diffie-Hellman Fails in Practice",
1570 Proceedings of the 22nd ACM SIGSAC Conference on Computer
1571 and Communications Security, pp. 5-17,
1572 DOI 10.1145/2810103.2813707, October 2015,
1573 <https://doi.org/10.1145/2810103.2813707>.
1575 [Multiple-Encryption]
1576 Merkle, R. and M. Hellman, "On the security of multiple
1577 encryption", Communications of the ACM, Vol. 24, Issue 7,
1578 pp. 465-467, DOI 10.1145/358699.358718, July 1981,
1579 <https://doi.org/10.1145/358699.358718>.
1582 National Institute of Standards and Technology,
1583 "Recommendation for Pair-Wise Key-Establishment Schemes
1584 Using Discrete Logarithm Cryptography", Revision 3, NIST
1585 Special Publication 800-56A,
1586 DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
1587 <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
1590 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size
1591 Does Matter: Attacks and Proofs for the TLS Record
1592 Protocol", Proceedings of the 17th International
1593 conference on The Theory and Application of Cryptology and
1594 Information Security, pp. 372-389,
1595 DOI 10.1007/978-3-642-25385-0_20, December 2011,
1596 <https://doi.org/10.1007/978-3-642-25385-0_20>.
1599 Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M.,
1600 and P. Rösler, "Attacking Deterministic Signature Schemes
1601 using Fault Attacks", Conference: 2018 IEEE European
1602 Symposium on Security and Privacy,
1603 DOI 10.1109/EuroSP.2018.00031, April 2018,
1604 <https://eprint.iacr.org/2017/1014.pdf>.
1606 [POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE
1607 Attack", October 2014,
1608 <https://www.us-cert.gov/ncas/alerts/TA14-290A>.
1610 [RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,
1611 Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and
1612 Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)",
1613 30th USENIX Security Symposium (USENIX Security 21), 2021,
1614 <https://www.usenix.org/conference/usenixsecurity21/
1615 presentation/merget>.
1617 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1618 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
1619 <https://www.rfc-editor.org/info/rfc2026>.
1621 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1622 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1623 <https://www.rfc-editor.org/info/rfc2246>.
1625 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1626 A., Peterson, J., Sparks, R., Handley, M., and E.
1627 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1628 DOI 10.17487/RFC3261, June 2002,
1629 <https://www.rfc-editor.org/info/rfc3261>.
1631 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
1632 Algorithm and Its Use with IPsec", RFC 3602,
1633 DOI 10.17487/RFC3602, September 2003,
1634 <https://www.rfc-editor.org/info/rfc3602>.
1636 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1637 (TLS) Protocol Version 1.1", RFC 4346,
1638 DOI 10.17487/RFC4346, April 2006,
1639 <https://www.rfc-editor.org/info/rfc4346>.
1641 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1642 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
1643 <https://www.rfc-editor.org/info/rfc4347>.
1645 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
1646 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
1647 <https://www.rfc-editor.org/info/rfc4949>.
1649 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
1650 "Transport Layer Security (TLS) Session Resumption without
1651 Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
1652 January 2008, <https://www.rfc-editor.org/info/rfc5077>.
1654 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
1655 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
1656 <https://www.rfc-editor.org/info/rfc5116>.
1658 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1659 Housley, R., and W. Polk, "Internet X.509 Public Key
1660 Infrastructure Certificate and Certificate Revocation List
1661 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1662 <https://www.rfc-editor.org/info/rfc5280>.
1664 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1665 DOI 10.17487/RFC5321, October 2008,
1666 <https://www.rfc-editor.org/info/rfc5321>.
1668 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
1669 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
1670 DOI 10.17487/RFC6101, August 2011,
1671 <https://www.rfc-editor.org/info/rfc6101>.
1673 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1674 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
1675 March 2011, <https://www.rfc-editor.org/info/rfc6120>.
1677 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1678 of Named Entities (DANE) Transport Layer Security (TLS)
1679 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
1680 2012, <https://www.rfc-editor.org/info/rfc6698>.
1682 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
1683 Transport Security (HSTS)", RFC 6797,
1684 DOI 10.17487/RFC6797, November 2012,
1685 <https://www.rfc-editor.org/info/rfc6797>.
1687 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
1688 Galperin, S., and C. Adams, "X.509 Internet Public Key
1689 Infrastructure Online Certificate Status Protocol - OCSP",
1690 RFC 6960, DOI 10.17487/RFC6960, June 2013,
1691 <https://www.rfc-editor.org/info/rfc6960>.
1693 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
1694 Multiple Certificate Status Request Extension", RFC 6961,
1695 DOI 10.17487/RFC6961, June 2013,
1696 <https://www.rfc-editor.org/info/rfc6961>.
1698 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
1699 Constrained-Node Networks", RFC 7228,
1700 DOI 10.17487/RFC7228, May 2014,
1701 <https://www.rfc-editor.org/info/rfc7228>.
1703 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1704 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1705 December 2014, <https://www.rfc-editor.org/info/rfc7435>.
1707 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
1708 Known Attacks on Transport Layer Security (TLS) and
1709 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
1710 February 2015, <https://www.rfc-editor.org/info/rfc7457>.
1712 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
1713 Suite Value (SCSV) for Preventing Protocol Downgrade
1714 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
1715 <https://www.rfc-editor.org/info/rfc7507>.
1717 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
1718 "Recommendations for Secure Use of Transport Layer
1719 Security (TLS) and Datagram Transport Layer Security
1720 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
1721 2015, <https://www.rfc-editor.org/info/rfc7525>.
1723 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
1724 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
1725 DOI 10.17487/RFC7568, June 2015,
1726 <https://www.rfc-editor.org/info/rfc7568>.
1728 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
1729 Security (TLS) in the Extensible Messaging and Presence
1730 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
1731 2015, <https://www.rfc-editor.org/info/rfc7590>.
1733 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
1734 Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
1735 October 2015, <https://www.rfc-editor.org/info/rfc7633>.
1737 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
1738 Opportunistic DNS-Based Authentication of Named Entities
1739 (DANE) Transport Layer Security (TLS)", RFC 7672,
1740 DOI 10.17487/RFC7672, October 2015,
1741 <https://www.rfc-editor.org/info/rfc7672>.
1743 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
1744 Based Authentication of Named Entities (DANE) TLSA Records
1745 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October
1746 2015, <https://www.rfc-editor.org/info/rfc7673>.
1748 [RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
1749 Associations (DNA) in the Extensible Messaging and
1750 Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712,
1751 November 2015, <https://www.rfc-editor.org/info/rfc7712>.
1753 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
1754 Ephemeral Parameters for Transport Layer Security (TLS)",
1755 RFC 7919, DOI 10.17487/RFC7919, August 2016,
1756 <https://www.rfc-editor.org/info/rfc7919>.
1758 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
1759 (TLS) Cached Information Extension", RFC 7924,
1760 DOI 10.17487/RFC7924, July 2016,
1761 <https://www.rfc-editor.org/info/rfc7924>.
1763 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
1764 Security (TLS) / Datagram Transport Layer Security (DTLS)
1765 Profiles for the Internet of Things", RFC 7925,
1766 DOI 10.17487/RFC7925, July 2016,
1767 <https://www.rfc-editor.org/info/rfc7925>.
1769 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV:
1770 Nonce Misuse-Resistant Authenticated Encryption",
1771 RFC 8452, DOI 10.17487/RFC8452, April 2019,
1772 <https://www.rfc-editor.org/info/rfc8452>.
1774 [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
1775 and J. Jones, "SMTP MTA Strict Transport Security (MTA-
1776 STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
1777 <https://www.rfc-editor.org/info/rfc8461>.
1779 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
1780 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
1781 2018, <https://www.rfc-editor.org/info/rfc8470>.
1783 [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
1784 Compression", RFC 8879, DOI 10.17487/RFC8879, December
1785 2020, <https://www.rfc-editor.org/info/rfc8879>.
1787 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
1788 Multiplexed and Secure Transport", RFC 9000,
1789 DOI 10.17487/RFC9000, May 2021,
1790 <https://www.rfc-editor.org/info/rfc9000>.
1792 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
1793 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
1794 <https://www.rfc-editor.org/info/rfc9001>.
1796 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
1797 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
1798 DOI 10.17487/RFC9051, August 2021,
1799 <https://www.rfc-editor.org/info/rfc9051>.
1801 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1802 Ed., "HTTP Semantics", STD 97, RFC 9110,
1803 DOI 10.17487/RFC9110, June 2022,
1804 <https://www.rfc-editor.org/info/rfc9110>.
1806 [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1807 Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
1808 June 2022, <https://www.rfc-editor.org/info/rfc9112>.
1810 [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
1811 DOI 10.17487/RFC9113, June 2022,
1812 <https://www.rfc-editor.org/info/rfc9113>.
1814 [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
1815 Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
1816 December 2021, <https://www.rfc-editor.org/info/rfc9162>.
1818 [RFC9191] Sethi, M., Preuß Mattsson, J., and S. Turner, "Handling
1819 Large Certificates and Long Certificate Chains in TLS-
1820 Based EAP Methods", RFC 9191, DOI 10.17487/RFC9191,
1821 February 2022, <https://www.rfc-editor.org/info/rfc9191>.
1824 Bernstein, D. J. and T. Lange, "SafeCurves: choosing safe
1825 curves for elliptic-curve cryptography", December 2014,
1826 <https://safecurves.cr.yp.to>.
1829 Soghoian, C. and S. Stamm, "Certified Lies: Detecting and
1830 Defeating Government Interception Attacks Against SSL",
1831 SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, April
1832 2010, <https://doi.org/10.2139/ssrn.1591033>.
1835 Springall, D., Durumeric, Z., and J. Halderman, "Measuring
1836 the Security Harm of TLS Crypto Shortcuts", Proceedings of
1837 the 2016 Internet Measurement Conference, pp. 33-47,
1838 DOI 10.1145/2987443.2987480, November 2016,
1839 <https://doi.org/10.1145/2987443.2987480>.
1841 [STD53] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
1842 STD 53, RFC 1939, May 1996.
1844 <https://www.rfc-editor.org/info/std53>
1846 [Sy2018] Sy, E., Burkert, C., Federrath, H., and M. Fischer,
1847 "Tracking Users across the Web via TLS Session
1848 Resumption", Proceedings of the 34th Annual Computer
1849 Security Applications Conference, pp. 289-299,
1850 DOI 10.1145/3274694.3274708, December 2018,
1851 <https://doi.org/10.1145/3274694.3274708>.
1853 [TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
1854 Encrypted Client Hello", Work in Progress, Internet-Draft,
1855 draft-ietf-tls-esni-15, 3 October 2022,
1856 <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
1860 Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and
1861 P. Strub, "Triple Handshakes and Cookie Cutters: Breaking
1862 and Fixing Authentication over TLS", 2014 IEEE Symposium
1863 on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014,
1864 <https://doi.org/10.1109/sp.2014.14>.
1866 [TWIRL] Shamir, A. and E. Tromer, "Factoring Large Numbers with
1867 the TWIRL Device", 2014 IEEE Symposium on Security and
1868 Privacy, DOI 10.1007/978-3-540-45146-4_1, 2004,
1869 <https://cs.tau.ac.il/~tromer/papers/twirl.pdf>.
1871Appendix A. Differences from RFC 7525
1873 This revision of the Best Current Practices contains numerous
1874 changes, and this section is focused on the normative changes.
1876 * High-level differences:
1878 - Described the expectations from new TLS-incorporating transport
1879 protocols and from new application protocols layered on TLS.
1881 - Clarified items (e.g., renegotiation) that only apply to TLS
1884 - Changed the status of TLS 1.0 and 1.1 from "SHOULD NOT" to
1887 - Added TLS 1.3 at a "SHOULD" level.
1889 - Made similar changes to DTLS.
1891 - Included specific guidance for multiplexed protocols.
1893 - MUST-level implementation requirement for ALPN and more
1894 specific SHOULD-level guidance for ALPN and SNI.
1896 - Clarified discussion of strict TLS policies, including MUST-
1897 level recommendations.
1899 - Limits on key usage.
1901 - New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, and
1902 "Nonce-Disrespecting Adversaries".
1904 - RFC 6961 (OCSP status_request_v2) has been deprecated.
1906 - MUST-level requirement for server-side RSA certificates to have
1907 a 2048-bit modulus at a minimum, replacing a "SHOULD".
1909 * Differences specific to TLS 1.2:
1911 - SHOULD-level guidance on AES-GCM nonce generation.
1913 - SHOULD NOT use (static or ephemeral) finite-field DH key
1916 - SHOULD NOT reuse ephemeral finite-field DH keys across multiple
1919 - SHOULD NOT use static Elliptic Curve DH key exchange.
1921 - 2048-bit DH is now a "MUST" and ECDH minimal curve size is 224
1922 (vs. 192 previously).
1924 - Support for extended_master_secret is now a "MUST" (previously
1925 it was a soft recommendation, as the RFC had not been published
1926 at the time). Also removed other, more complicated, related
1929 - MUST-level restriction on session ticket validity, replacing a
1932 - SHOULD-level restriction on the TLS session duration, depending
1933 on the rotation period of an [RFC5077] ticket key.
1935 - Dropped TLS_DHE_RSA_WITH_AES from the recommended ciphers.
1937 - Added TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers.
1939 - SHOULD NOT use the old MTI cipher suite,
1940 TLS_RSA_WITH_AES_128_CBC_SHA.
1942 - Recommended curve X25519 alongside NIST P-256.
1944 * Differences specific to TLS 1.3:
1946 - New TLS 1.3 capabilities: 0-RTT.
1948 - Removed capabilities: renegotiation and compression.
1950 - Added mention of TLS Encrypted Client Hello, but no
1951 recommendation for use until it is finalized.
1953 - SHOULD-level requirement for forward secrecy in TLS 1.3 session
1956 - Generic MUST-level guidance to avoid 0-RTT unless it is
1957 documented for the particular protocol.
1961 Thanks to Alexey Melnikov, Alvaro Retana, Andrei Popov, Ben Kaduk,
1962 Christian Huitema, Corey Bonnell, Cullen Jennings, Daniel Kahn
1963 Gillmor, David Benjamin, Eric Rescorla, Éric Vyncke, Francesca
1964 Palombini, Hannes Tschofenig, Hubert Kario, Ilari Liusvaara, John
1965 Preuß Mattsson, John R. Levine, Julien Élie, Lars Eggert, Leif
1966 Johansson, Magnus Westerlund, Martin Duke, Martin Thomson, Mohit
1967 Sahni, Nick Sullivan, Nimrod Aviram, Paul Wouters, Peter Gutmann,
1968 Rich Salz, Robert Sayre, Robert Wilton, Roman Danyliw, Ryan Sleevi,
1969 Sean Turner, Stephen Farrell, Tim Evans, Valery Smyslov, Viktor
1970 Dukhovni, and Warren Kumari for helpful comments and discussions that
1971 have shaped this document.
1973 The authors gratefully acknowledge the contribution of Ralph Holz,
1974 who was a coauthor of RFC 7525, the previous version of the TLS
1977 See RFC 7525 for additional acknowledgments specific to the previous
1978 version of the TLS recommendations.
1984 Email: yaronf.ietf@gmail.com
1989 Email: stpeter@stpeter.im
1994 Email: thomas.fossati@arm.com