idnits 2.17.1 draft-ietf-uta-rfc7525bis-06.txt: -(1349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC7525, but the abstract doesn't seem to directly say this. It does mention RFC7525 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5288, updated by this document, for RFC5378 checks: 2007-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 March 2022) is 763 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Obsolete normative reference: RFC 8740 (Obsoleted by RFC 9113) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-aead-limits-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7507 (Obsoleted by RFC 8996) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Obsoletes: 7525 (if approved) P. Saint-Andre 5 Updates: 5288, 6066 (if approved) independent 6 Intended status: Best Current Practice T. Fossati 7 Expires: 25 September 2022 arm 8 24 March 2022 10 Recommendations for Secure Use of Transport Layer Security (TLS) and 11 Datagram Transport Layer Security (DTLS) 12 draft-ietf-uta-rfc7525bis-06 14 Abstract 16 Transport Layer Security (TLS) and Datagram Transport Layer Security 17 (DTLS) are widely used to protect data exchanged over application 18 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the 19 years, the industry has witnessed several serious attacks on TLS and 20 DTLS, including attacks on the most commonly used cipher suites and 21 their modes of operation. This document provides recommendations for 22 improving the security of deployed services that use TLS and DTLS. 23 The recommendations are applicable to the majority of use cases. 25 An earlier version of this document was published as RFC 7525 when 26 the industry was in the midst of its transition to TLS 1.2. Years 27 later this transition is largely complete and TLS 1.3 is widely 28 available. This document updates the guidance, given the new 29 environment. In addition, the document updates RFC 5288 and RFC 6066 30 in view of recent attacks. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 25 September 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. General Recommendations . . . . . . . . . . . . . . . . . . . 5 68 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5 70 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6 71 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7 72 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 75 3.5. Renegotiation in TLS 1.2 . . . . . . . . . . . . . . . . 9 76 3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 10 77 3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10 78 3.8. Application-Layer Protocol Negotiation . . . . . . . . . 11 79 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11 80 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 12 81 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 12 82 4.2. Cipher Suites for TLS 1.2 . . . . . . . . . . . . . . . . 13 83 4.2.1. Implementation Details . . . . . . . . . . . . . . . 14 84 4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 15 85 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15 86 4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 16 87 4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 17 88 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 17 89 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 18 90 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 19 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 19 94 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 7.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 20 96 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 21 97 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 22 98 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 23 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 102 9.2. Informative References . . . . . . . . . . . . . . . . . 27 103 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 34 104 Appendix B. Document History . . . . . . . . . . . . . . . . . . 36 105 B.1. draft-ietf-uta-rfc7525bis-06 . . . . . . . . . . . . . . 36 106 B.2. draft-ietf-uta-rfc7525bis-05 . . . . . . . . . . . . . . 36 107 B.3. draft-ietf-uta-rfc7525bis-04 . . . . . . . . . . . . . . 36 108 B.4. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 36 109 B.5. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 37 110 B.6. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 37 111 B.7. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 37 112 B.8. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 38 113 B.9. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 38 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 116 1. Introduction 118 Transport Layer Security (TLS) and Datagram Transport Security Layer 119 (DTLS) are widely used to protect data exchanged over application 120 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the 121 years leading to 2015, the industry has witnessed serious attacks on 122 TLS and DTLS, including attacks on the most commonly used cipher 123 suites and their modes of operation. For instance, both the AES-CBC 124 [RFC3602] and RC4 [RFC7465] encryption algorithms, which together 125 were once the most widely deployed ciphers, have been attacked in the 126 context of TLS. A companion document [RFC7457] provides detailed 127 information about these attacks and will help the reader understand 128 the rationale behind the recommendations provided here. That 129 document has not been updated in concert with this one; instead, 130 newer attacks are described in this document, as are mitigations for 131 those attacks. 133 The TLS community reacted to these attacks in several ways: 135 * Detailed guidance was published on the use of TLS 1.2 [RFC5246] 136 and DTLS 1.2 [RFC6347], along with earlier protocol versions. 137 This guidance is included in the original [RFC7525] and mostly 138 retained in this revised version; note that this guidance was 139 mostly adopted by the industry since the publication of RFC 7525 140 in 2015. 142 * Versions of TLS earlier than 1.2 were deprecated [RFC8996]. 144 * Version 1.3 of TLS [RFC8446] was released and version 1.3 of DTLS 145 was finalized [I-D.ietf-tls-dtls13]; these versions largely 146 mitigate or resolve the described attacks. 148 Those who implement and deploy TLS and DTLS, in particular versions 149 1.2 or earlier of these protocols, need guidance on how TLS can be 150 used securely. This document provides guidance for deployed services 151 as well as for software implementations, assuming the implementer 152 expects his or her code to be deployed in environments defined in 153 Section 5. Concerning deployment, this document targets a wide 154 audience -- namely, all deployers who wish to add authentication (be 155 it one-way only or mutual), confidentiality, and data integrity 156 protection to their communications. 158 The recommendations herein take into consideration the security of 159 various mechanisms, their technical maturity and interoperability, 160 and their prevalence in implementations at the time of writing. 161 Unless it is explicitly called out that a recommendation applies to 162 TLS alone or to DTLS alone, each recommendation applies to both TLS 163 and DTLS. 165 This document attempts to minimize new guidance to TLS 1.2 166 implementations, and the overall approach is to encourage systems to 167 move to TLS 1.3. However this is not always practical. Newly 168 discovered attacks, as well as ecosystem changes, necessitated some 169 new requirements that apply to TLS 1.2 environments. Those are 170 summarized in Appendix A. 172 As noted, the TLS 1.3 specification resolves many of the 173 vulnerabilities listed in this document. A system that deploys TLS 174 1.3 should have fewer vulnerabilities than TLS 1.2 or below. This 175 document is being republished with this in mind, and with an explicit 176 goal to migrate most uses of TLS 1.2 into TLS 1.3. 178 These are minimum recommendations for the use of TLS in the vast 179 majority of implementation and deployment scenarios, with the 180 exception of unauthenticated TLS (see Section 5). Other 181 specifications that reference this document can have stricter 182 requirements related to one or more aspects of the protocol, based on 183 their particular circumstances (e.g., for use with a particular 184 application protocol); when that is the case, implementers are 185 advised to adhere to those stricter requirements. Furthermore, this 186 document provides a floor, not a ceiling, so stronger options are 187 always allowed (e.g., depending on differing evaluations of the 188 importance of cryptographic strength vs. computational load). 190 Community knowledge about the strength of various algorithms and 191 feasible attacks can change quickly, and experience shows that a Best 192 Current Practice (BCP) document about security is a point-in-time 193 statement. Readers are advised to seek out any errata or updates 194 that apply to this document. 196 2. Terminology 198 A number of security-related terms in this document are used in the 199 sense defined in [RFC4949]. 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in 204 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 3. General Recommendations 209 This section provides general recommendations on the secure use of 210 TLS. Recommendations related to cipher suites are discussed in the 211 following section. 213 3.1. Protocol Versions 215 3.1.1. SSL/TLS Protocol Versions 217 It is important both to stop using old, less secure versions of SSL/ 218 TLS and to start using modern, more secure versions; therefore, the 219 following are the recommendations concerning TLS/SSL protocol 220 versions: 222 * Implementations MUST NOT negotiate SSL version 2. 224 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 226 * Implementations MUST NOT negotiate SSL version 3. 228 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 229 plugged some significant security holes but did not support strong 230 cipher suites. SSLv3 does not support TLS extensions, some of 231 which (e.g., renegotiation_info [RFC5746]) are security-critical. 232 In addition, with the emergence of the POODLE attack [POODLE], 233 SSLv3 is now widely recognized as fundamentally insecure. See 234 [DEP-SSLv3] for further details. 236 * Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 238 Rationale: TLS 1.0 (published in 1999) does not support many 239 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 240 record Initialization Vector (IV) for CBC-based cipher suites and 241 does not warn against common padding errors. This and other 242 recommendations in this section are in line with [RFC8996]. 244 * Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 246 Rationale: TLS 1.1 (published in 2006) is a security improvement 247 over TLS 1.0 but still does not support certain stronger cipher 248 suites. 250 * Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to 251 negotiate TLS version 1.2 over earlier versions of TLS. 253 Rationale: Several stronger cipher suites are available only with 254 TLS 1.2 (published in 2008). In fact, the cipher suites 255 recommended by this document for TLS 1.2 (Section 4.2 below) are 256 only available in this version. 258 * Implementations SHOULD support TLS 1.3 [RFC8446] and, if 259 implemented, MUST prefer to negotiate TLS 1.3 over earlier 260 versions of TLS. 262 Rationale: TLS 1.3 is a major overhaul to the protocol and 263 resolves many of the security issues with TLS 1.2. We note that 264 as long as TLS 1.2 is still allowed by a particular 265 implementation, even if it defaults to TLS 1.3, implementers MUST 266 still follow all the recommendations in this document. 268 * Implementations of "greenfield" protocols or deployments, where 269 there is no need to support legacy endpoints, SHOULD support TLS 270 1.3, with no negotiation of earlier versions. Similarly, we 271 RECOMMEND that new protocol designs that embed the TLS mechanisms 272 (such as QUIC has done [RFC9001]) include TLS 1.3. 274 Rationale: secure deployment of TLS 1.3 is significantly easier 275 and less error prone than the secure deployment of TLS 1.2. 277 This BCP applies to TLS 1.2, 1.3 and to earlier versions. It is not 278 safe for readers to assume that the recommendations in this BCP apply 279 to any future version of TLS. 281 3.1.2. DTLS Protocol Versions 283 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 284 1.1 was published. The following are the recommendations with 285 respect to DTLS: 287 * Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347]. 289 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 291 * Implementations MUST support DTLS 1.2 [RFC6347] and MUST prefer to 292 negotiate DTLS version 1.2 over earlier versions of DTLS. 294 Version 1.2 of DTLS correlates to version 1.2 of TLS (see above). 295 (There is no version 1.1 of DTLS.) 297 * Implementations SHOULD support DTLS 1.3 [I-D.ietf-tls-dtls13] and, 298 if implemented, MUST prefer to negotiate DTLS version 1.3 over 299 earlier versions of DTLS. 301 Version 1.3 of DTLS correlates to version 1.3 of TLS (see above). 303 3.1.3. Fallback to Lower Versions 305 TLS/DTLS 1.2 clients MUST NOT fall back to earlier TLS versions, 306 since those versions have been deprecated [RFC8996]. We note that as 307 a result of that, the SCSV mechanism [RFC7507] is no longer needed 308 for clients. In addition, TLS 1.3 implements a new version 309 negotiation mechanism. 311 3.2. Strict TLS 313 The following recommendations are provided to help prevent SSL 314 Stripping (an attack that is summarized in Section 2.1 of [RFC7457]): 316 * In cases where an application protocol allows implementations or 317 deployments a choice between strict TLS configuration and dynamic 318 upgrade from unencrypted to TLS-protected traffic (such as 319 STARTTLS), clients and servers SHOULD prefer strict TLS 320 configuration. 322 * Application protocols typically provide a way for the server to 323 offer TLS during an initial protocol exchange, and sometimes also 324 provide a way for the server to advertise support for TLS (e.g., 325 through a flag indicating that TLS is required); unfortunately, 326 these indications are sent before the communication channel is 327 encrypted. A client SHOULD attempt to negotiate TLS even if these 328 indications are not communicated by the server. 330 * HTTP client and server implementations MUST support the HTTP 331 Strict Transport Security (HSTS) header [RFC6797], in order to 332 allow Web servers to advertise that they are willing to accept 333 TLS-only clients. 335 * Web servers SHOULD use HSTS to indicate that they are willing to 336 accept TLS-only clients, unless they are deployed in such a way 337 that using HSTS would in fact weaken overall security (e.g., it 338 can be problematic to use HSTS with self-signed certificates, as 339 described in Section 11.3 of [RFC6797]). 341 Rationale: Combining unprotected and TLS-protected communication 342 opens the way to SSL Stripping and similar attacks, since an initial 343 part of the communication is not integrity protected and therefore 344 can be manipulated by an attacker whose goal is to keep the 345 communication in the clear. 347 3.3. Compression 349 In order to help prevent compression-related attacks (summarized in 350 Section 2.6 of [RFC7457]), when using TLS 1.2 implementations and 351 deployments SHOULD disable TLS-level compression (Section 6.2.2 of 352 [RFC5246]), unless the application protocol in question has been 353 shown not to be open to such attacks. Note: this recommendation 354 applies to TLS 1.2 only, because compression has been removed from 355 TLS 1.3. 357 Rationale: TLS compression has been subject to security attacks, such 358 as the CRIME attack. 360 Implementers should note that compression at higher protocol levels 361 can allow an active attacker to extract cleartext information from 362 the connection. The BREACH attack is one such case. These issues 363 can only be mitigated outside of TLS and are thus outside the scope 364 of this document. See Section 2.6 of [RFC7457] for further details. 366 3.4. TLS Session Resumption 368 Session resumption drastically reduces the number of TLS handshakes 369 and thus is an essential performance feature for most deployments. 371 Stateless session resumption with session tickets is a popular 372 strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, a 373 more secure PSK-based mechanism is described in Section 4.6.1 of 374 [RFC8446]. See this post (https://blog.filippo.io/we-need-to-talk- 375 about-session-tickets/) by Filippo Valsorda for a comparison of TLS 376 1.2 and 1.3 session resumption, and [Springall16] for a quantitative 377 study of TLS cryptographic "shortcuts", including session resumption. 379 When it is used, the resumption information MUST be authenticated and 380 encrypted to prevent modification or eavesdropping by an attacker. 381 Further recommendations apply to session tickets: 383 * A strong cipher suite MUST be used when encrypting the ticket (as 384 least as strong as the main TLS cipher suite). 386 * Ticket keys MUST be changed regularly, e.g., once every week, so 387 as not to negate the benefits of forward secrecy (see Section 7.3 388 for details on forward secrecy). Old ticket keys MUST be 389 destroyed shortly after a new key version is made available. 391 * For similar reasons, session ticket validity SHOULD be limited to 392 a reasonable duration (e.g., half as long as ticket key validity). 394 * TLS 1.2 does not roll the session key forward within a single 395 session. Thus, to prevent an attack where a stolen ticket key is 396 used to decrypt the entire content of a session (negating the 397 concept of forward secrecy), a TLS 1.2 server SHOULD NOT resume 398 sessions that are too old, e.g. sessions that have been open 399 longer than two ticket key rotation periods. Note that this 400 implies that some server implementations might need to abort 401 sessions after a certain duration. 403 Rationale: session resumption is another kind of TLS handshake, and 404 therefore must be as secure as the initial handshake. This document 405 (Section 4) recommends the use of cipher suites that provide forward 406 secrecy, i.e. that prevent an attacker who gains momentary access to 407 the TLS endpoint (either client or server) and its secrets from 408 reading either past or future communication. The tickets must be 409 managed so as not to negate this security property. 411 TLS 1.3 provides the powerful option of forward secrecy even within a 412 long-lived connection that is periodically resumed. Section 2.2 of 413 [RFC8446] recommends that clients SHOULD send a "key_share" when 414 initiating session resumption. In order to gain forward secrecy, 415 this document recommends that server implementations SHOULD respond 416 with a "key_share", to complete an ECDHE exchange on each session 417 resumption. 419 TLS session resumption introduces potential privacy issues where the 420 server is able to track the client, in some cases indefinitely. See 421 [Sy2018] for more details. 423 3.5. Renegotiation in TLS 1.2 425 The recommendations in this section apply to TLS 1.2 only, because 426 renegotiation has been removed from TLS 1.3. 428 TLS 1.2 clients and servers MUST implement the renegotiation_info 429 extension, as defined in [RFC5746]. 431 TLS 1.2 clients MUST send renegotiation_info in the Client Hello. If 432 the server does not acknowledge the extension, the client MUST 433 generate a fatal handshake_failure alert prior to terminating the 434 connection. 436 Rationale: It is not safe for a client to connect to a TLS 1.2 server 437 that does not support renegotiation_info, regardless of whether 438 either endpoint actually implements renegotiation. See also 439 Section 4.1 of [RFC5746]. 441 A related attack resulting from TLS session parameters not properly 442 authenticated is Triple Handshake [triple-handshake]. To address 443 this attack, TLS 1.2 implementations SHOULD support the 444 extended_master_secret extension defined in [RFC7627]. 446 3.6. Post-Handshake Authentication 448 Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post- 449 handshake authentication and key update mechanisms. In the context 450 of protocols that multiplex requests over a single connection (such 451 as HTTP/2), post-handshake authentication has the same problems as 452 TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the 453 advice provided for HTTP/2 in [RFC8740]. 455 3.7. Server Name Indication 457 TLS implementations MUST support the Server Name Indication (SNI) 458 extension defined in Section 3 of [RFC6066] for those higher-level 459 protocols that would benefit from it, including HTTPS. However, the 460 actual use of SNI in particular circumstances is a matter of local 461 policy. Implementers are strongly encouraged to support TLS 462 Encrypted Client Hello (formerly called Encrypted SNI) once 463 [I-D.ietf-tls-esni] has been standardized. 465 Rationale: SNI supports deployment of multiple TLS-protected virtual 466 servers on a single address, and therefore enables fine-grained 467 security for these virtual servers, by allowing each one to have its 468 own certificate. However, SNI also leaks the target domain for a 469 given connection; this information leak will be plugged by use of TLS 470 Encrypted Client Hello. 472 In order to prevent the attacks described in [ALPACA], a server that 473 does not recognize the presented server name SHOULD NOT continue the 474 handshake and instead SHOULD fail with a fatal-level 475 unrecognized_name(112) alert. Note that this recommendation updates 476 Section 3 of [RFC6066]: "If the server understood the ClientHello 477 extension but does not recognize the server name, the server SHOULD 478 take one of two actions: either abort the handshake by sending a 479 fatal-level unrecognized_name(112) alert or continue the handshake." 480 It is also RECOMMENDED that clients abort the handshake if the server 481 acknowledges the SNI extension, but presents a certificate with a 482 different hostname than the one sent by the client. 484 3.8. Application-Layer Protocol Negotiation 486 TLS implementations (both client- and server-side) MUST support the 487 Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. 489 In order to prevent "cross-protocol" attacks resulting from failure 490 to ensure that a message intended for use in one protocol cannot be 491 mistaken for a message for use in another protocol, servers should 492 strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: 493 "In the event that the server supports no protocols that the client 494 advertises, then the server SHALL respond with a fatal 495 no_application_protocol alert." It is also RECOMMENDED that clients 496 abort the handshake if the server acknowledges the ALPN extension, 497 but does not select a protocol from the client list. Failure to do 498 so can result in attacks such those described in [ALPACA]. 500 Protocol developers are strongly encouraged to register an ALPN 501 identifier for their protocols. This applies to new protocols, as 502 well as well-established protocols such as SMTP. 504 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 506 The 0-RTT early data feature is new in TLS 1.3. It provides improved 507 latency when TLS connections are resumed, at the potential cost of 508 security. As a result, it requires special attention from 509 implementers on both the server and the client side. Typically this 510 extends to both the TLS library as well as protocol layers above it. 512 For use in HTTP-over-TLS, readers are referred to [RFC8470] for 513 guidance. 515 For QUIC-on-TLS, refer to Sec. 9.2 of [RFC9001]. 517 For other protocols, generic guidance is given in Sec. 8 and 518 Appendix E.5 of [RFC8446]. To paraphrase Appendix E.5, applications 519 MUST avoid this feature unless an explicit specification exists for 520 the application protocol in question to clarify when 0-RTT is 521 appropriate and secure. This can take the form of an IETF RFC, a 522 non-IETF standard, or even documentation associated with a non- 523 standard protocol. 525 4. Recommendations: Cipher Suites 527 TLS and its implementations provide considerable flexibility in the 528 selection of cipher suites. Unfortunately, the security of some of 529 these cipher suites has degraded over time to the point where some 530 are known to be insecure. Incorrectly configuring a server leads to 531 no or reduced security. This section includes recommendations on the 532 selection and negotiation of cipher suites. 534 4.1. General Guidelines 536 Cryptographic algorithms weaken over time as cryptanalysis improves: 537 algorithms that were once considered strong become weak. Such 538 algorithms need to be phased out over time and replaced with more 539 secure cipher suites. This helps to ensure that the desired security 540 properties still hold. SSL/TLS has been in existence for almost 20 541 years and many of the cipher suites that have been recommended in 542 various versions of SSL/TLS are now considered weak or at least not 543 as strong as desired. Therefore, this section modernizes the 544 recommendations concerning cipher suite selection. 546 * Implementations MUST NOT negotiate the cipher suites with NULL 547 encryption. 549 Rationale: The NULL cipher suites do not encrypt traffic and so 550 provide no confidentiality services. Any entity in the network 551 with access to the connection can view the plaintext of contents 552 being exchanged by the client and server. 553 Nevertheless, this document does not discourage software from 554 implementing NULL cipher suites, since they can be useful for 555 testing and debugging. 557 * Implementations MUST NOT negotiate RC4 cipher suites. 559 Rationale: The RC4 stream cipher has a variety of cryptographic 560 weaknesses, as documented in [RFC7465]. Note that DTLS 561 specifically forbids the use of RC4 already. 563 * Implementations MUST NOT negotiate cipher suites offering less 564 than 112 bits of security, including so-called "export-level" 565 encryption (which provide 40 or 56 bits of security). 567 Rationale: Based on [RFC3766], at least 112 bits of security is 568 needed. 40-bit and 56-bit security are considered insecure today. 569 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 571 * Implementations SHOULD NOT negotiate cipher suites that use 572 algorithms offering less than 128 bits of security. 574 Rationale: Cipher suites that offer between 112-bits and 128-bits 575 of security are not considered weak at this time; however, it is 576 expected that their useful lifespan is short enough to justify 577 supporting stronger cipher suites at this time. 128-bit ciphers 578 are expected to remain secure for at least several years, and 579 256-bit ciphers until the next fundamental technology 580 breakthrough. Note that, because of so-called "meet-in-the- 581 middle" attacks [Multiple-Encryption], some legacy cipher suites 582 (e.g., 168-bit 3DES) have an effective key length that is smaller 583 than their nominal key length (112 bits in the case of 3DES). 584 Such cipher suites should be evaluated according to their 585 effective key length. 587 * Implementations SHOULD NOT negotiate cipher suites based on RSA 588 key transport, a.k.a. "static RSA". 590 Rationale: These cipher suites, which have assigned values 591 starting with the string "TLS_RSA_WITH_*", have several drawbacks, 592 especially the fact that they do not support forward secrecy. 594 * Implementations SHOULD NOT negotiate cipher suites based on non- 595 ephemeral (static) finite-field Diffie-Hellman key agreement. 597 Rationale: These cipher suites, which have assigned values 598 prefixed by "TLS_DH_*", have several drawbacks, especially the 599 fact that they do not support forward secrecy. 601 * Implementations MUST support and prefer to negotiate cipher suites 602 offering forward secrecy. However, TLS 1.2 implementations SHOULD 603 NOT negotiate cipher suites based on ephemeral finite-field 604 Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites). This is 605 justified by the known fragility of the construction (see 606 [RACCOON]) and the limitation around negotiation -- including 607 using [RFC7919], which has seen very limited uptake. 609 Rationale: Forward secrecy (sometimes called "perfect forward 610 secrecy") prevents the recovery of information that was encrypted 611 with older session keys, thus limiting the amount of time during 612 which attacks can be successful. See Section 7.3 for a detailed 613 discussion. 615 4.2. Cipher Suites for TLS 1.2 617 Given the foregoing considerations, implementation and deployment of 618 the following cipher suites is RECOMMENDED: 620 * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 621 * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 623 * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 625 * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 627 These cipher suites are supported only in TLS 1.2 and not in earlier 628 protocol versions, because they are authenticated encryption (AEAD) 629 algorithms [RFC5116]. 631 Typically, in order to prefer these suites, the order of suites needs 632 to be explicitly configured in server software. (See [BETTERCRYPTO] 633 for helpful deployment guidelines, but note that its recommendations 634 differ from the current document in some details.) It would be ideal 635 if server software implementations were to prefer these suites by 636 default. 638 Some devices have hardware support for AES-CCM but not AES-GCM, so 639 they are unable to follow the foregoing recommendations regarding 640 cipher suites. There are even devices that do not support public key 641 cryptography at all, but they are out of scope entirely. 643 When using ECDSA signatures for authentication of TLS peers, it is 644 RECOMMENDED that implementations use the NIST curve P-256. In 645 addition, to avoid predictable or repeated nonces (that would allow 646 revealing the long term signing key), it is RECOMMENDED that 647 implementations implement "deterministic ECDSA" as specified in 648 [RFC6979] and in line with the recommendations in [RFC8446]. 650 4.2.1. Implementation Details 652 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 653 first proposal to any server, unless they have prior knowledge that 654 the server cannot respond to a TLS 1.2 client_hello message. 656 Servers MUST prefer this cipher suite over weaker cipher suites 657 whenever it is proposed, even if it is not the first proposal. 659 Clients are of course free to offer stronger cipher suites, e.g., 660 using AES-256; when they do, the server SHOULD prefer the stronger 661 cipher suite unless there are compelling reasons (e.g., seriously 662 degraded performance) to choose otherwise. 664 The previous version of this document implicitly allowed the old RFC 665 5246 mandatory-to-implement cipher suite, 666 TLS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher 667 suite does not provide additional interoperability, except with 668 extremely old clients. As with other cipher suites that do not 669 provide forward secrecy, implementations SHOULD NOT support this 670 cipher suite. Other application protocols specify other cipher 671 suites as mandatory to implement (MTI). 673 [RFC8422] allows clients and servers to negotiate ECDH parameters 674 (curves). Both clients and servers SHOULD include the "Supported 675 Elliptic Curves" extension [RFC8422]. Clients and servers SHOULD 676 support the NIST P-256 (secp256r1) [RFC8422] and X25519 (x25519) 677 [RFC7748] curves. Note that [RFC8422] deprecates all but the 678 uncompressed point format. Therefore, if the client sends an 679 ec_point_formats extension, the ECPointFormatList MUST contain a 680 single element, "uncompressed". 682 4.3. Cipher Suites for TLS 1.3 684 This document does not specify any cipher suites for TLS 1.3. 685 Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite 686 recommendations. 688 4.4. Limits on Key Usage 690 All ciphers have an upper limit on the amount of traffic that can be 691 securely protected with any given key. In the case of AEAD cipher 692 suites, two separate limits are maintained for each key: 694 1. Confidentiality limit (CL), i.e., the number of records that can 695 be encrypted. 697 2. Integrity limit (IL), i.e., the number of records that are 698 allowed to fail authentication. 700 The latter only applies to DTLS since TLS connections are torn down 701 on the first decryption failure. 703 When a sender is approaching CL, the implementation SHOULD initiate a 704 new handshake (or in TLS 1.3, a Key Update) to rotate the session 705 key. 707 When a receiver has reached IL, the implementation SHOULD close the 708 connection. 710 For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of 711 [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher 712 suites, readers are referred to Section 4.5.3 of 713 [I-D.ietf-tls-dtls13]. 715 For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in 716 this document, CL can be derived by plugging the corresponding 717 parameters into the inequalities in Section 6.1 of 718 [I-D.irtf-cfrg-aead-limits] that apply to random, partially implicit 719 nonces, i.e., the nonce construction used in TLS 1.2. Although the 720 obtained figures are slightly higher than those for TLS 1.3, it is 721 RECOMMENDED that the same limit of 2^24.5 records is used for both 722 versions. 724 For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained 725 from the same inequalities referenced above) is 2^28. 727 4.5. Public Key Length 729 When using the cipher suites recommended in this document, two public 730 keys are normally used in the TLS handshake: one for the Diffie- 731 Hellman key agreement and one for server authentication. Where a 732 client certificate is used, a third public key is added. 734 With a key exchange based on modular exponential (MODP) Diffie- 735 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 736 bits are REQUIRED. 738 Rationale: For various reasons, in practice, DH keys are typically 739 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 740 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 741 would be roughly equivalent to only an 80-bit symmetric key 742 [RFC3766], it is better to use keys longer than that for the "DHE" 743 family of cipher suites. A DH key of 1926 bits would be roughly 744 equivalent to a 100-bit symmetric key [RFC3766]. A DH key of 2048 745 bits (equivalent to a 112-bit symmetric key) is the minimum allowed 746 by the latest revision of [NIST.SP.800-56A], as of this writing (see 747 in particular Appendix D). 749 As noted in [RFC3766], correcting for the emergence of a TWIRL 750 machine would imply that 1024-bit DH keys yield about 65 bits of 751 equivalent strength and that a 2048-bit DH key would yield about 92 752 bits of equivalent strength. The Logjam attack [Logjam] further 753 demonstrates that 1024-bit Diffie Hellman parameters should be 754 avoided. 756 With regard to ECDH keys, implementers are referred to the IANA 757 "Supported Groups Registry" (former "EC Named Curve Registry"), 758 within the "Transport Layer Security (TLS) Parameters" registry 759 [IANA_TLS], and in particular to the "recommended" groups. Curves of 760 less than 224 bits MUST NOT be used. This recommendation is in-line 761 with the latest revision of [NIST.SP.800-56A]. 763 When using RSA, servers SHOULD authenticate using certificates with 764 at least a 2048-bit modulus for the public key. In addition, the use 765 of the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST 766 NOT be used ([RFC9155], and see [CAB-Baseline] for more details). 767 Clients MUST indicate to servers that they request SHA-256, by using 768 the "Signature Algorithms" extension defined in TLS 1.2. 770 4.6. Truncated HMAC 772 Implementations MUST NOT use the Truncated HMAC extension, defined in 773 Section 7 of [RFC6066]. 775 Rationale: the extension does not apply to the AEAD cipher suites 776 recommended above. However it does apply to most other TLS cipher 777 suites. Its use has been shown to be insecure in [PatersonRS11]. 779 5. Applicability Statement 781 The recommendations of this document primarily apply to the 782 implementation and deployment of application protocols that are most 783 commonly used with TLS and DTLS on the Internet today. Examples 784 include, but are not limited to: 786 * Web software and services that wish to protect HTTP traffic with 787 TLS. 789 * Email software and services that wish to protect IMAP, POP3, or 790 SMTP traffic with TLS. 792 * Instant-messaging software and services that wish to protect 793 Extensible Messaging and Presence Protocol (XMPP) or Internet 794 Relay Chat (IRC) traffic with TLS. 796 * Realtime media software and services that wish to protect Secure 797 Realtime Transport Protocol (SRTP) traffic with DTLS. 799 This document does not modify the implementation and deployment 800 recommendations (e.g., mandatory-to-implement cipher suites) 801 prescribed by existing application protocols that employ TLS or DTLS. 802 If the community that uses such an application protocol wishes to 803 modernize its usage of TLS or DTLS to be consistent with the best 804 practices recommended here, it needs to explicitly update the 805 existing application protocol definition (one example is [RFC7590], 806 which updates [RFC6120]). 808 Designers of new application protocols developed through the Internet 809 Standards Process [RFC2026] are expected at minimum to conform to the 810 best practices recommended here, unless they provide documentation of 811 compelling reasons that would prevent such conformance (e.g., 812 widespread deployment on constrained devices that lack support for 813 the necessary algorithms). 815 5.1. Security Services 817 This document provides recommendations for an audience that wishes to 818 secure their communication with TLS to achieve the following: 820 * Confidentiality: all application-layer communication is encrypted 821 with the goal that no party should be able to decrypt it except 822 the intended receiver. 824 * Data integrity: any changes made to the communication in transit 825 are detectable by the receiver. 827 * Authentication: an endpoint of the TLS communication is 828 authenticated as the intended entity to communicate with. 830 With regard to authentication, TLS enables authentication of one or 831 both endpoints in the communication. In the context of opportunistic 832 security [RFC7435], TLS is sometimes used without authentication. As 833 discussed in Section 5.2, considerations for opportunistic security 834 are not in scope for this document. 836 If deployers deviate from the recommendations given in this document, 837 they need to be aware that they might lose access to one of the 838 foregoing security services. 840 This document applies only to environments where confidentiality is 841 required. It recommends algorithms and configuration options that 842 enforce secrecy of the data in transit. 844 This document also assumes that data integrity protection is always 845 one of the goals of a deployment. In cases where integrity is not 846 required, it does not make sense to employ TLS in the first place. 847 There are attacks against confidentiality-only protection that 848 utilize the lack of integrity to also break confidentiality (see, for 849 instance, [DegabrieleP07] in the context of IPsec). 851 This document addresses itself to application protocols that are most 852 commonly used on the Internet with TLS and DTLS. Typically, all 853 communication between TLS clients and TLS servers requires all three 854 of the above security services. This is particularly true where TLS 855 clients are user agents like Web browsers or email software. 857 This document does not address the rarer deployment scenarios where 858 one of the above three properties is not desired, such as the use 859 case described in Section 5.2 below. As another scenario where 860 confidentiality is not needed, consider a monitored network where the 861 authorities in charge of the respective traffic domain require full 862 access to unencrypted (plaintext) traffic, and where users 863 collaborate and send their traffic in the clear. 865 5.2. Opportunistic Security 867 There are several important scenarios in which the use of TLS is 868 optional, i.e., the client decides dynamically ("opportunistically") 869 whether to use TLS with a particular server or to connect in the 870 clear. This practice, often called "opportunistic security", is 871 described at length in [RFC7435] and is often motivated by a desire 872 for backward compatibility with legacy deployments. 874 In these scenarios, some of the recommendations in this document 875 might be too strict, since adhering to them could cause fallback to 876 cleartext, a worse outcome than using TLS with an outdated protocol 877 version or cipher suite. 879 6. IANA Considerations 881 This document has no IANA actions. 883 7. Security Considerations 885 This entire document discusses the security practices directly 886 affecting applications using the TLS protocol. This section contains 887 broader security considerations related to technologies used in 888 conjunction with or by TLS. 890 7.1. Host Name Validation 892 Application authors should take note that some TLS implementations do 893 not validate host names. If the TLS implementation they are using 894 does not validate host names, authors might need to write their own 895 validation code or consider using a different TLS implementation. 897 It is noted that the requirements regarding host name validation 898 (and, in general, binding between the TLS layer and the protocol that 899 runs above it) vary between different protocols. For HTTPS, these 900 requirements are defined by Sections 4.3.3, 4.3.4 and 4.3.5 of 901 [I-D.ietf-httpbis-semantics]. 903 Readers are referred to [RFC6125] for further details regarding 904 generic host name validation in the TLS context. In addition, that 905 RFC contains a long list of example protocols, some of which 906 implement a policy very different from HTTPS. 908 If the host name is discovered indirectly and in an insecure manner 909 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 910 NOT be used as a reference identifier [RFC6125] even when it matches 911 the presented certificate. This proviso does not apply if the host 912 name is discovered securely (for further discussion, see [DANE-SRV] 913 and [DANE-SMTP]). 915 Host name validation typically applies only to the leaf "end entity" 916 certificate. Naturally, in order to ensure proper authentication in 917 the context of the PKI, application clients need to verify the entire 918 certification path in accordance with [RFC5280] (see also [RFC6125]). 920 7.2. AES-GCM 922 Section 4.2 above recommends the use of the AES-GCM authenticated 923 encryption algorithm. Please refer to Section 11 of [RFC5246] for 924 general security considerations when using TLS 1.2, and to Section 6 925 of [RFC5288] for security considerations that apply specifically to 926 AES-GCM when used with TLS. 928 7.2.1. Nonce Reuse in TLS 1.2 930 The existence of deployed TLS stacks that mistakenly reuse the AES- 931 GCM nonce is documented in [Boeck2016], showing there is an actual 932 risk of AES-GCM getting implemented in an insecure way and thus 933 making TLS sessions that use an AES-GCM cipher suite vulnerable to 934 attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE- 935 2016-10213, CVE-2016-10212, CVE-2017-5933.) 937 While this problem has been fixed in TLS 1.3, which enforces a 938 deterministic method to generate nonces from record sequence numbers 939 and shared secrets for all of its AEAD cipher suites (including AES- 940 GCM), TLS 1.2 implementations could still choose their own 941 (potentially insecure) nonce generation methods. 943 It is therefore RECOMMENDED that TLS 1.2 implementations use the 944 64-bit sequence number to populate the nonce_explicit part of the GCM 945 nonce, as described in the first two paragraphs of Section 5.3 of 946 [RFC8446]. Note that this stronger recommendation updates Section 3 947 of [RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number." 948 We note that at the time of writing there are no cipher suites 949 defined for nonce reuse resistant algorithms such as AES-GCM-SIV 950 [RFC8452]. 952 7.3. Forward Secrecy 954 Forward secrecy (also called "perfect forward secrecy" or "PFS" and 955 defined in [RFC4949]) is a defense against an attacker who records 956 encrypted conversations where the session keys are only encrypted 957 with the communicating parties' long-term keys. 959 Should the attacker be able to obtain these long-term keys at some 960 point later in time, the session keys and thus the entire 961 conversation could be decrypted. 963 In the context of TLS and DTLS, such compromise of long-term keys is 964 not entirely implausible. It can happen, for example, due to: 966 * A client or server being attacked by some other attack vector, and 967 the private key retrieved. 969 * A long-term key retrieved from a device that has been sold or 970 otherwise decommissioned without prior wiping. 972 * A long-term key used on a device as a default key [Heninger2012]. 974 * A key generated by a trusted third party like a CA, and later 975 retrieved from it either by extortion or compromise 976 [Soghoian2011]. 978 * A cryptographic break-through, or the use of asymmetric keys with 979 insufficient length [Kleinjung2010]. 981 * Social engineering attacks against system administrators. 983 * Collection of private keys from inadequately protected backups. 985 Forward secrecy ensures in such cases that it is not feasible for an 986 attacker to determine the session keys even if the attacker has 987 obtained the long-term keys some time after the conversation. It 988 also protects against an attacker who is in possession of the long- 989 term keys but remains passive during the conversation. 991 Forward secrecy is generally achieved by using the Diffie-Hellman 992 scheme to derive session keys. The Diffie-Hellman scheme has both 993 parties maintain private secrets and send parameters over the network 994 as modular powers over certain cyclic groups. The properties of the 995 so-called Discrete Logarithm Problem (DLP) allow the parties to 996 derive the session keys without an eavesdropper being able to do so. 997 There is currently no known attack against DLP if sufficiently large 998 parameters are chosen. A variant of the Diffie-Hellman scheme uses 999 elliptic curves instead of the originally proposed modular 1000 arithmetic. Given the current state of the art, elliptic-curve 1001 Diffie-Hellman appears to be more efficient, permits shorter key 1002 lengths, and allows less freedom for implementation errors than 1003 finite-field Diffie-Hellman. 1005 Unfortunately, many TLS/DTLS cipher suites were defined that do not 1006 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This 1007 document therefore advocates strict use of forward-secrecy-only 1008 ciphers. 1010 7.4. Diffie-Hellman Exponent Reuse 1012 For performance reasons, many TLS implementations reuse Diffie- 1013 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 1014 connections. Such reuse can result in major security issues: 1016 * If exponents are reused for too long (in some cases, even as 1017 little as a few hours), an attacker who gains access to the host 1018 can decrypt previous connections. In other words, exponent reuse 1019 negates the effects of forward secrecy. 1021 * TLS implementations that reuse exponents should test the DH public 1022 key they receive for group membership, in order to avoid some 1023 known attacks. These tests are not standardized in TLS at the 1024 time of writing, although general guidance in this area is 1025 provided by [NIST.SP.800-56A] and available in many protocol 1026 implementations. 1028 * Under certain conditions, the use of static finite-field DH keys, 1029 or of ephemeral finite-field DH keys that are reused across 1030 multiple connections, can lead to timing attacks (such as those 1031 described in [RACCOON]) on the shared secrets used in Diffie- 1032 Hellman key exchange. 1034 * An "invalid curve" attack can be mounted against elliptic-curve DH 1035 if the victim does not verify that the received point lies on the 1036 correct curve. If the victim is reusing the DH secrets, the 1037 attacker can repeat the probe varying the points to recover the 1038 full secret (see [Antipa2003] and [Jager2015]). 1040 To address these concerns: 1042 * TLS implementations SHOULD NOT use static finite-field DH keys and 1043 SHOULD NOT reuse ephemeral finite-field DH keys across multiple 1044 connections. 1046 * Server implementations that want to reuse elliptic-curve DH keys 1047 SHOULD either use a "safe curve" [SAFECURVES] (e.g., X25519), or 1048 perform the checks described in [NIST.SP.800-56A] on the received 1049 points. 1051 7.5. Certificate Revocation 1053 The following considerations and recommendations represent the 1054 current state of the art regarding certificate revocation, even 1055 though no complete and efficient solution exists for the problem of 1056 checking the revocation status of common public key certificates 1057 [RFC5280]: 1059 * Certificate revocation is an important tool when recovering from 1060 attacks on the TLS implementation, as well as cases of misissued 1061 certificates. TLS implementations MUST implement a strategy to 1062 distrust revoked certificates. 1064 * Although Certificate Revocation Lists (CRLs) are the most widely 1065 supported mechanism for distributing revocation information, they 1066 have known scaling challenges that limit their usefulness, despite 1067 workarounds such as partitioned CRLs and delta CRLs. The more 1068 modern [CRLite] and the follow-on Let's Revoke [LetsRevoke] build 1069 on the availability of Certificate Transparency [RFC9162] logs and 1070 aggressive compression to allow practical use of the CRL 1071 infrastructure, but at the time of writing, neither solution is 1072 deployed for client-side revocation processing at scale. 1074 * Proprietary mechanisms that embed revocation lists in the Web 1075 browser's configuration database cannot scale beyond a small 1076 number of the most heavily used Web servers. 1078 * The On-Line Certification Status Protocol (OCSP) [RFC6960] in its 1079 basic form presents both scaling and privacy issues. In addition, 1080 clients typically "soft-fail", meaning that they do not abort the 1081 TLS connection if the OCSP server does not respond. (However, 1082 this might be a workaround to avoid denial-of-service attacks if 1083 an OCSP responder is taken offline.). For an up-to-date survey of 1084 the status of OCSP deployment in the Web PKI see [Chung18]. 1086 * The TLS Certificate Status Request extension (Section 8 of 1087 [RFC6066]), commonly called "OCSP stapling", resolves the 1088 operational issues with OCSP. However, it is still ineffective in 1089 the presence of a MITM attacker because the attacker can simply 1090 ignore the client's request for a stapled OCSP response. 1092 * [RFC7633] defines a certificate extension that indicates that 1093 clients must expect stapled OCSP responses for the certificate and 1094 must abort the handshake ("hard-fail") if such a response is not 1095 available. 1097 * OCSP stapling as used in TLS 1.2 does not extend to intermediate 1098 certificates within a certificate chain. The Multiple Certificate 1099 Status extension [RFC6961] addresses this shortcoming, but it has 1100 seen little deployment and had been deprecated by [RFC8446]. As a 1101 result, we no longer recommend this extension for TLS 1.2. 1103 * TLS 1.3 (Section 4.4.2.1 of [RFC8446]) allows the association of 1104 OCSP information with intermediate certificates by using an 1105 extension to the CertificateEntry structure. However using this 1106 facility remains impractical because many CAs either do not 1107 publish OCSP for CA certificates or publish OCSP reports with a 1108 lifetime that is too long to be useful. 1110 * Both CRLs and OCSP depend on relatively reliable connectivity to 1111 the Internet, which might not be available to certain kinds of 1112 nodes. A common example is newly provisioned devices that need to 1113 establish a secure connection in order to boot up for the first 1114 time. 1116 For the common use cases of public key certificates in TLS, servers 1117 SHOULD support the following as a best practice given the current 1118 state of the art and as a foundation for a possible future solution: 1119 OCSP [RFC6960] and OCSP stapling using the status_request extension 1120 defined in [RFC6066]. Note that the exact mechanism for embedding 1121 the status_request extension differs between TLS 1.2 and 1.3. As a 1122 matter of local policy, server operators MAY request that CAs issue 1123 must-staple [RFC7633] certificates for the server and/or for client 1124 authentication, but we recommend to review the operational conditions 1125 before deciding on this approach. 1127 The considerations in this section do not apply to scenarios where 1128 the DANE-TLSA resource record [RFC6698] is used to signal to a client 1129 which certificate a server considers valid and good to use for TLS 1130 connections. 1132 8. Acknowledgments 1134 Thanks to Alexey Melnikov, Andrei Popov, Christian Huitema, Daniel 1135 Kahn Gillmor, David Benjamin, Eric Rescorla, Hannes Tschofenig, 1136 Hubert Kario, Ilari Liusvaara, John Mattsson, John R Levine, Julien 1137 Élie, Leif Johansson, Martin Thomson, Mohit Sahni, Nick Sullivan, 1138 Nimrod Aviram, Rich Salz, Ryan Sleevi, Sean Turner, Valery Smyslov, 1139 Viktor Dukhovni for helpful comments and discussions that have shaped 1140 this document. 1142 The authors gratefully acknowledge the contribution of Ralph Holz, 1143 who was a coauthor of RFC 7525, the previous version of this 1144 document. 1146 See RFC 7525 for additional acknowledgments for the previous revision 1147 of this document. 1149 9. References 1151 9.1. Normative References 1153 [I-D.ietf-httpbis-semantics] 1154 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1155 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1156 httpbis-semantics-19, 12 September 2021, 1157 . 1160 [I-D.ietf-tls-dtls13] 1161 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1162 Datagram Transport Layer Security (DTLS) Protocol Version 1163 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1164 dtls13-43, 30 April 2021, 1165 . 1168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1169 Requirement Levels", BCP 14, RFC 2119, 1170 DOI 10.17487/RFC2119, March 1997, 1171 . 1173 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1174 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1175 RFC 3766, DOI 10.17487/RFC3766, April 2004, 1176 . 1178 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1179 (TLS) Protocol Version 1.2", RFC 5246, 1180 DOI 10.17487/RFC5246, August 2008, 1181 . 1183 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1184 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1185 DOI 10.17487/RFC5288, August 2008, 1186 . 1188 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1189 "Transport Layer Security (TLS) Renegotiation Indication 1190 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 1191 . 1193 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1194 Extensions: Extension Definitions", RFC 6066, 1195 DOI 10.17487/RFC6066, January 2011, 1196 . 1198 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1199 Verification of Domain-Based Application Service Identity 1200 within Internet Public Key Infrastructure Using X.509 1201 (PKIX) Certificates in the Context of Transport Layer 1202 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1203 2011, . 1205 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 1206 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 1207 2011, . 1209 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1210 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1211 January 2012, . 1213 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1214 Algorithm (DSA) and Elliptic Curve Digital Signature 1215 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1216 2013, . 1218 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1219 "Transport Layer Security (TLS) Application-Layer Protocol 1220 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1221 July 2014, . 1223 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 1224 DOI 10.17487/RFC7465, February 2015, 1225 . 1227 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1228 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1229 Session Hash and Extended Master Secret Extension", 1230 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1231 . 1233 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1234 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1235 2016, . 1237 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1238 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1239 May 2017, . 1241 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1242 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1243 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1244 DOI 10.17487/RFC8422, August 2018, 1245 . 1247 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1248 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1249 . 1251 [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, 1252 DOI 10.17487/RFC8740, February 2020, 1253 . 1255 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1256 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1257 . 1259 [RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating 1260 MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2", 1261 RFC 9155, DOI 10.17487/RFC9155, December 2021, 1262 . 1264 9.2. Informative References 1266 [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., 1267 Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, 1268 "ALPACA: Application Layer Protocol Confusion - Analyzing 1269 and Mitigating Cracks in TLS Authentication", 30th USENIX 1270 Security Symposium (USENIX Security 21) , 2021, 1271 . 1274 [Antipa2003] 1275 Antipa, A., Brown, D.R.L., Menezes, A., Struik, R., and 1276 S.A. Vanstone, "Validation of Elliptic Curve Public Keys", 1277 Public Key Cryptography - PKC 2003 , 2003. 1279 [BETTERCRYPTO] 1280 bettercrypto.org, "Applied Crypto Hardening", April 2015, 1281 . 1283 [Boeck2016] 1284 Böck, H., Zauner, A., Devlin, S., Somorovsky, J., and P. 1285 Jovanovic, "Nonce-Disrespecting Adversaries: Practical 1286 Forgery Attacks on GCM in TLS", May 2016, 1287 . 1289 [CAB-Baseline] 1290 CA/Browser Forum, "Baseline Requirements for the Issuance 1291 and Management of Publicly-Trusted Certificates Version 1292 1.1.6", 2013, . 1294 [Chung18] Chung, T., Lok, J., Chandrasekaran, B., Choffnes, D., 1295 Levin, D., Maggs, B., Mislove, A., Rula, J., Sullivan, N., 1296 and C. Wilson, "Is the Web Ready for OCSP Must-Staple?", 1297 Proceedings of the Internet Measurement Conference 2018, 1298 DOI 10.1145/3278532.3278543, October 2018, 1299 . 1301 [CRLite] Larisch, J., Choffnes, D., Levin, D., Maggs, B., Mislove, 1302 A., and C. Wilson, "CRLite: A Scalable System for Pushing 1303 All TLS Revocations to All Browsers", 2017 IEEE Symposium 1304 on Security and Privacy (SP), DOI 10.1109/sp.2017.17, May 1305 2017, . 1307 [CVE] MITRE, "Common Vulnerabilities and Exposures", 1308 . 1310 [DANE-SMTP] 1311 Dukhovni, V. and W. Hardaker, "SMTP Security via 1312 Opportunistic DNS-Based Authentication of Named Entities 1313 (DANE) Transport Layer Security (TLS)", RFC 7672, 1314 DOI 10.17487/RFC7672, October 2015, 1315 . 1317 [DANE-SRV] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1318 Based Authentication of Named Entities (DANE) TLSA Records 1319 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1320 2015, . 1322 [DegabrieleP07] 1323 Degabriele, J. and K. Paterson, "Attacking the IPsec 1324 Standards in Encryption-only Configurations", 2007 IEEE 1325 Symposium on Security and Privacy (SP '07), 1326 DOI 10.1109/sp.2007.8, May 2007, 1327 . 1329 [DEP-SSLv3] 1330 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1331 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 1332 DOI 10.17487/RFC7568, June 2015, 1333 . 1335 [Heninger2012] 1336 Heninger, N., Durumeric, Z., Wustrow, E., and J.A. 1337 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1338 Weak Keys in Network Devices", Usenix Security 1339 Symposium 2012, 2012. 1341 [I-D.ietf-tls-esni] 1342 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1343 Encrypted Client Hello", Work in Progress, Internet-Draft, 1344 draft-ietf-tls-esni-14, 13 February 2022, 1345 . 1348 [I-D.irtf-cfrg-aead-limits] 1349 Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on 1350 AEAD Algorithms", Work in Progress, Internet-Draft, draft- 1351 irtf-cfrg-aead-limits-04, 7 March 2022, 1352 . 1355 [IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters", 1356 . 1358 [Jager2015] 1359 Jager, T., Schwenk, J., and J. Somorovsky, "Practical 1360 Invalid Curve Attacks on TLS-ECDH", European Symposium on 1361 Research in Computer Security (ESORICS) 2015 , 2015. 1363 [Joux2006] Joux, A., "Authentication Failures in NIST version of 1364 GCM", 2006, . 1368 [Kleinjung2010] 1369 Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé, 1370 E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P., 1371 Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann, 1372 "Factorization of a 768-Bit RSA Modulus", Advances in 1373 Cryptology - CRYPTO 2010 pp. 333-350, 1374 DOI 10.1007/978-3-642-14623-7_18, 2010, 1375 . 1377 [LetsRevoke] 1378 Smith, T., Dickinson, L., and K. Seamons, "Let's Revoke: 1379 Scalable Global Certificate Revocation", Proceedings 2020 1380 Network and Distributed System Security Symposium, 1381 DOI 10.14722/ndss.2020.24084, 2020, 1382 . 1384 [Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 1385 Green, M., Halderman, J., Heninger, N., Springall, D., 1386 Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., 1387 Zanella-Béguelin, S., and P. Zimmermann, "Imperfect 1388 Forward Secrecy: How Diffie-Hellman Fails in Practice", 1389 Proceedings of the 22nd ACM SIGSAC Conference on Computer 1390 and Communications Security, DOI 10.1145/2810103.2813707, 1391 October 2015, . 1393 [Multiple-Encryption] 1394 Merkle, R. and M. Hellman, "On the security of multiple 1395 encryption", Communications of the ACM Vol. 24, pp. 1396 465-467, DOI 10.1145/358699.358718, July 1981, 1397 . 1399 [NIST.SP.800-56A] 1400 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1401 Davis, "Recommendation for pair-wise key-establishment 1402 schemes using discrete logarithm cryptography", National 1403 Institute of Standards and Technology report, 1404 DOI 10.6028/nist.sp.800-56ar3, April 2018, 1405 . 1407 [PatersonRS11] 1408 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 1409 Does Matter: Attacks and Proofs for the TLS Record 1410 Protocol", Lecture Notes in Computer Science pp. 372-389, 1411 DOI 10.1007/978-3-642-25385-0_20, 2011, 1412 . 1414 [POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE 1415 Attack", October 2014, 1416 . 1418 [RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J., 1419 Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and 1420 Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)", 1421 30th USENIX Security Symposium (USENIX Security 21) , 1422 2021, . 1425 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1426 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1427 . 1429 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1430 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1431 . 1433 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1434 Algorithm and Its Use with IPsec", RFC 3602, 1435 DOI 10.17487/RFC3602, September 2003, 1436 . 1438 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1439 (TLS) Protocol Version 1.1", RFC 4346, 1440 DOI 10.17487/RFC4346, April 2006, 1441 . 1443 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1444 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1445 . 1447 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1448 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1449 . 1451 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1452 "Transport Layer Security (TLS) Session Resumption without 1453 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1454 January 2008, . 1456 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1457 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1458 . 1460 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1461 Housley, R., and W. Polk, "Internet X.509 Public Key 1462 Infrastructure Certificate and Certificate Revocation List 1463 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1464 . 1466 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1467 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1468 DOI 10.17487/RFC6101, August 2011, 1469 . 1471 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1472 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1473 March 2011, . 1475 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1476 of Named Entities (DANE) Transport Layer Security (TLS) 1477 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1478 2012, . 1480 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1481 Transport Security (HSTS)", RFC 6797, 1482 DOI 10.17487/RFC6797, November 2012, 1483 . 1485 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1486 Galperin, S., and C. Adams, "X.509 Internet Public Key 1487 Infrastructure Online Certificate Status Protocol - OCSP", 1488 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1489 . 1491 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1492 Multiple Certificate Status Request Extension", RFC 6961, 1493 DOI 10.17487/RFC6961, June 2013, 1494 . 1496 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1497 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1498 December 2014, . 1500 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1501 Known Attacks on Transport Layer Security (TLS) and 1502 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1503 February 2015, . 1505 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1506 Suite Value (SCSV) for Preventing Protocol Downgrade 1507 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 1508 . 1510 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1511 "Recommendations for Secure Use of Transport Layer 1512 Security (TLS) and Datagram Transport Layer Security 1513 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1514 2015, . 1516 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 1517 Security (TLS) in the Extensible Messaging and Presence 1518 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 1519 2015, . 1521 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 1522 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 1523 October 2015, . 1525 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 1526 Ephemeral Parameters for Transport Layer Security (TLS)", 1527 RFC 7919, DOI 10.17487/RFC7919, August 2016, 1528 . 1530 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 1531 Nonce Misuse-Resistant Authenticated Encryption", 1532 RFC 8452, DOI 10.17487/RFC8452, April 2019, 1533 . 1535 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1536 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1537 2018, . 1539 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1540 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1541 . 1543 [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate 1544 Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, 1545 December 2021, . 1547 [SAFECURVES] 1548 Bernstein, D.J. and T. Lange, "SafeCurves: Choosing Safe 1549 Curves for Elliptic-Curve Cryptography", December 2014, 1550 . 1552 [Soghoian2011] 1553 Soghoian, C. and S. Stamm, "Certified Lies: Detecting and 1554 Defeating Government Interception Attacks Against SSL", 1555 SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010, 1556 . 1558 [Springall16] 1559 Springall, D., Durumeric, Z., and J. Halderman, "Measuring 1560 the Security Harm of TLS Crypto Shortcuts", Proceedings of 1561 the 2016 Internet Measurement Conference, 1562 DOI 10.1145/2987443.2987480, November 2016, 1563 . 1565 [Sy2018] Sy, E., Burkert, C., Federrath, H., and M. Fischer, 1566 "Tracking Users across the Web via TLS Session 1567 Resumption", Proceedings of the 34th Annual Computer 1568 Security Applications Conference, 1569 DOI 10.1145/3274694.3274708, December 2018, 1570 . 1572 [triple-handshake] 1573 Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and 1574 P. Strub, "Triple Handshakes and Cookie Cutters: Breaking 1575 and Fixing Authentication over TLS", 2014 IEEE Symposium 1576 on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014, 1577 . 1579 Appendix A. Differences from RFC 7525 1581 This revision of the Best Current Practices contains numerous 1582 changes, and this section is focused on the normative changes. 1584 * High level differences: 1586 - Clarified items (e.g. renegotiation) that only apply to TLS 1587 1.2. 1589 - Changed status of TLS 1.0 and 1.1 from SHOULD NOT to MUST NOT. 1591 - Added TLS 1.3 at a SHOULD level. 1593 - Similar changes to DTLS, pending publication of DTLS 1.3. 1595 - Specific guidance for multiplexed protocols. 1597 - MUST-level implementation requirement for ALPN, and more 1598 specific SHOULD-level guidance for ALPN and SNI. 1600 - Limits on key usage. 1602 - New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce- 1603 Disrespecting Adversaries". 1605 - RFC 6961 (OCSP status_request_v2) has been deprecated. 1607 * Differences specific to TLS 1.2: 1609 - SHOULD-level guidance on AES-GCM nonce generation. 1611 - SHOULD NOT use (static or ephemeral) finite-field DH key 1612 agreement. 1614 - SHOULD NOT reuse ephemeral finite-field DH keys across multiple 1615 connections. 1617 - 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192 1618 previously. 1620 - Support for extended_master_secret is a SHOULD. Also removed 1621 other, more complicated, related mitigations. 1623 - SHOULD-level restriction on the TLS session duration, depending 1624 on the rotation period of an [RFC5077] ticket key. 1626 - Drop TLS_DHE_RSA_WITH_AES from the recommended ciphers 1628 - Add TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers 1630 - SHOULD NOT use the old MTI cipher suite, 1631 TLS_RSA_WITH_AES_128_CBC_SHA. 1633 - Recommend curve X25519 alongside NIST P-256 1635 * Differences specific to TLS 1.3: 1637 - New TLS 1.3 capabilities: 0-RTT. 1639 - Removed capabilities: renegotiation, compression. 1641 - Added mention of TLS Encrypted Client Hello, but no 1642 recommendation to use until it is finalized. 1644 - SHOULD-level requirement for forward secrecy in TLS 1.3 session 1645 resumption. 1647 - Generic SHOULD-level guidance to avoid 0-RTT unless it is 1648 documented for the particular protocol. 1650 Appendix B. Document History 1652 // Note to RFC Editor: please remove before publication. 1654 B.1. draft-ietf-uta-rfc7525bis-06 1656 * Addressed several I-D nits raised by the document shepherd. 1658 B.2. draft-ietf-uta-rfc7525bis-05 1660 * Addressed WG Last Call comments, specifically: 1662 - More clarity and guidance on session resumption. 1664 - Clarity on TLS 1.2 renegotiation. 1666 - Wording on the 0-RTT feature aligned with RFC 8446. 1668 - SHOULD NOT guidance on static and ephemeral finite field DH 1669 cipher suites. 1671 - Revamped the recommended TLS 1.2 cipher suites, removing DHE 1672 and adding ECDSA. The latter due to the wide adoption of ECDSA 1673 certificates and in line with RFC 8446. 1675 - Recommendation to use deterministic ECDSA. 1677 - Finally deprecated the old TLS 1.2 MTI cipher suite. 1679 - Deeper discussion of ECDH public key reuse issues, and as a 1680 result, recommended support of X25519. 1682 - Reworded the section on certificate revocation and OCSP 1683 following a long mailing list thread. 1685 B.3. draft-ietf-uta-rfc7525bis-04 1687 * No version fallback from TLS 1.2 to earlier versions, therefore no 1688 SCSV. 1690 B.4. draft-ietf-uta-rfc7525bis-03 1692 * Cipher integrity and confidentiality limits. 1694 * Require extended_master_secret. 1696 B.5. draft-ietf-uta-rfc7525bis-02 1698 * Adjusted text about ALPN support in application protocols 1700 * Incorporated text from draft-ietf-tls-md5-sha1-deprecate 1702 B.6. draft-ietf-uta-rfc7525bis-01 1704 * Many more changes, including: 1706 - SHOULD-level requirement for forward secrecy in TLS 1.3 session 1707 resumption. 1709 - Removed TLS 1.2 capabilities: renegotiation, compression. 1711 - Specific guidance for multiplexed protocols. 1713 - MUST-level implementation requirement for ALPN, and more 1714 specific SHOULD-level guidance for ALPN and SNI. 1716 - Generic SHOULD-level guidance to avoid 0-RTT unless it is 1717 documented for the particular protocol. 1719 - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. 1721 - SHOULD NOT use static DH keys or reuse ephemeral DH keys across 1722 multiple connections. 1724 - 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from 1725 192. 1727 B.7. draft-ietf-uta-rfc7525bis-00 1729 * Renamed: WG document. 1731 * Started populating list of changes from RFC 7525. 1733 * General rewording of abstract and intro for revised version. 1735 * Protocol versions, fallback. 1737 * Reference to ECHO. 1739 B.8. draft-sheffer-uta-rfc7525bis-00 1741 * Renamed, since the BCP number does not change. 1743 * Added an empty "Differences from RFC 7525" section. 1745 B.9. draft-sheffer-uta-bcp195bis-00 1747 * Initial release, the RFC 7525 text as-is, with some minor 1748 editorial changes to the references. 1750 Authors' Addresses 1752 Yaron Sheffer 1753 Intuit 1754 Email: yaronf.ietf@gmail.com 1756 Peter Saint-Andre 1757 independent 1758 Email: stpeter@stpeter.im 1760 Thomas Fossati 1761 arm 1762 Email: thomas.fossati@arm.com