idnits 2.17.1 draft-ietf-uta-rfc7525bis-00.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- 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 -- The document date (October 30, 2020) is 1273 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) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-12) exists of draft-ietf-tls-oldversions-deprecate-08 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** 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) ** Obsolete normative reference: RFC 7507 (Obsoleted by RFC 8996) == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-32 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-08 -- 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 7525 (Obsoleted by RFC 9325) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 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) R. Holz 5 Intended status: Best Current Practice University of Twente 6 Expires: May 3, 2021 P. Saint-Andre 7 Mozilla 8 October 30, 2020 10 Recommendations for Secure Use of Transport Layer Security (TLS) and 11 Datagram Transport Layer Security (DTLS) 12 draft-ietf-uta-rfc7525bis-00 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 last few years, several serious attacks on TLS have emerged, 20 including attacks on its most commonly used cipher suites and their 21 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 This document was published as RFC 7525 when the industry was in the 26 midst of its transition to TLS 1.2. Years later this transition is 27 largely complete and TLS 1.3 is widely available. Given the new 28 environment, we believe new guidance is needed. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 3, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. General Recommendations . . . . . . . . . . . . . . . . . . . 4 67 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 4 68 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 4 69 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6 70 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 6 71 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 74 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 8 75 3.6. Server Name Indication . . . . . . . . . . . . . . . . . 9 76 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 9 77 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 9 78 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 11 79 4.2.1. Implementation Details . . . . . . . . . . . . . . . 11 80 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 12 81 4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites . 13 82 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 14 83 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 14 84 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 15 85 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 16 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 6.1. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 17 89 6.3. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 18 90 6.4. Certificate Revocation . . . . . . . . . . . . . . . . . 18 91 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 8.2. Informative References . . . . . . . . . . . . . . . . . 22 96 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 28 97 Appendix B. Document History . . . . . . . . . . . . . . . . . . 28 98 B.1. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 28 99 B.2. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 28 100 B.3. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 28 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 103 1. Introduction 105 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 106 Security Layer (DTLS) [RFC6347] are widely used to protect data 107 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 108 SIP, and XMPP. Over the years leading to 2015, several serious 109 attacks on TLS have emerged, including attacks on its most commonly 110 used cipher suites and their modes of operation. For instance, both 111 the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which 112 together have been the most widely deployed ciphers, have been 113 attacked in the context of TLS. A companion document [RFC7457] 114 provides detailed information about these attacks and will help the 115 reader understand the rationale behind the recommendations provided 116 here. 118 The TLS community reacted to these attacks in two ways: 120 o Detailed guidance was published on the use of TLS 1.2 and earlier 121 protocol versions. This guidance is included in the original 122 [RFC7525] and mostly retained in this revised version. 123 o A new protocol version was released, TLS 1.3 [RFC8446], which 124 largely mitigates or resolves these attacks. 126 Those who implement and deploy TLS and DTLS, in particular versions 127 1.2 or earlier of these protocols, need guidance on how TLS can be 128 used securely. This document provides guidance for deployed services 129 as well as for software implementations, assuming the implementer 130 expects his or her code to be deployed in environments defined in 131 Section 5. Concerning deployment, this document targets a wide 132 audience - namely, all deployers who wish to add authentication (be 133 it one-way only or mutual), confidentiality, and data integrity 134 protection to their communications. 136 The recommendations herein take into consideration the security of 137 various mechanisms, their technical maturity and interoperability, 138 and their prevalence in implementations at the time of writing. 139 Unless it is explicitly called out that a recommendation applies to 140 TLS alone or to DTLS alone, each recommendation applies to both TLS 141 and DTLS. 143 As noted, the TLS 1.3 specification resolves many of the 144 vulnerabilities listed in this document. A system that deploys TLS 145 1.3 should have fewer vulnerabilities than TLS 1.2 or below. This 146 document is being republished with this in mind, and with an explicit 147 goal to migrate most uses of TLS 1.2 into TLS 1.3. 149 These are minimum recommendations for the use of TLS in the vast 150 majority of implementation and deployment scenarios, with the 151 exception of unauthenticated TLS (see Section 5). Other 152 specifications that reference this document can have stricter 153 requirements related to one or more aspects of the protocol, based on 154 their particular circumstances (e.g., for use with a particular 155 application protocol); when that is the case, implementers are 156 advised to adhere to those stricter requirements. Furthermore, this 157 document provides a floor, not a ceiling, so stronger options are 158 always allowed (e.g., depending on differing evaluations of the 159 importance of cryptographic strength vs. computational load). 161 Community knowledge about the strength of various algorithms and 162 feasible attacks can change quickly, and experience shows that a Best 163 Current Practice (BCP) document about security is a point-in-time 164 statement. Readers are advised to seek out any errata or updates 165 that apply to this document. 167 2. Terminology 169 A number of security-related terms in this document are used in the 170 sense defined in [RFC4949]. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 3. General Recommendations 180 This section provides general recommendations on the secure use of 181 TLS. Recommendations related to cipher suites are discussed in the 182 following section. 184 3.1. Protocol Versions 186 3.1.1. SSL/TLS Protocol Versions 188 It is important both to stop using old, less secure versions of SSL/ 189 TLS and to start using modern, more secure versions; therefore, the 190 following are the recommendations concerning TLS/SSL protocol 191 versions: 193 o Implementations MUST NOT negotiate SSL version 2. 195 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 196 o Implementations MUST NOT negotiate SSL version 3. 198 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 199 plugged some significant security holes but did not support strong 200 cipher suites. SSLv3 does not support TLS extensions, some of 201 which (e.g., renegotiation_info [RFC5746]) are security-critical. 202 In addition, with the emergence of the POODLE attack [POODLE], 203 SSLv3 is now widely recognized as fundamentally insecure. See 204 [DEP-SSLv3] for further details. 205 o Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. 207 Rationale: TLS 1.0 (published in 1999) does not support many 208 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 209 record Initialization Vector (IV) for CBC-based cipher suites and 210 does not warn against common padding errors. 212 NOTE: This recommendation has been changed from SHOULD NOT to MUST 213 NOT on the assumption that [I-D.ietf-tls-oldversions-deprecate] 214 will be published as an RFC before this document. 215 o Implementations MUST NOT negotiate TLS version 1.1 [RFC4346]. 217 Rationale: TLS 1.1 (published in 2006) is a security improvement 218 over TLS 1.0 but still does not support certain stronger cipher 219 suites. 221 NOTE: This recommendation has been changed from SHOULD NOT to MUST 222 NOT on the assumption that [I-D.ietf-tls-oldversions-deprecate] 223 will be published as an RFC before this document. 224 o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to 225 negotiate TLS version 1.2 over earlier versions of TLS. 227 Rationale: Several stronger cipher suites are available only with 228 TLS 1.2 (published in 2008). In fact, the cipher suites 229 recommended by this document for TLS 1.2 (Section 4.2 below) are 230 only available in this version. 231 o Implementations SHOULD support TLS 1.3 [RFC8446] and if 232 implemented, MUST prefer to negotiate TLS 1.3 over earlier 233 versions of TLS. 235 Rationale: TLS 1.3 is a major overhaul to the protocol and 236 resolves many of the security issues with TLS 1.2. We note that 237 as long as TLS 1.2 is still allowed by a particular 238 implementation, even if it defaults to TLS 1.3, implementers MUST 239 still follow all the recommendations in this document. 240 o Implementations of "greenfield" protocols or deployments, where 241 there is no need to support legacy endpoints, SHOULD support TLS 242 1.3, with no negotiation of earlier versions. Similarly, we 243 RECOMMEND that new protocol designs that embed the TLS mechanisms 244 (such as QUIC has done [I-D.ietf-quic-tls]) include TLS 1.3. 246 Rationale: secure deployment of TLS 1.3 is significantly easier 247 and less error prone than the secure deployment of TLS 1.2. 249 This BCP applies to TLS 1.2, 1.3 and to earlier versions. It is not 250 safe for readers to assume that the recommendations in this BCP apply 251 to any future version of TLS. 253 3.1.2. DTLS Protocol Versions 255 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 256 1.1 was published. The following are the recommendations with 257 respect to DTLS: 259 o Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347]. 261 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 263 NOTE: This recommendation has been changed from SHOULD NOT to MUST 264 NOT on the assumption that [I-D.ietf-tls-oldversions-deprecate] 265 will be published as an RFC before this document. 266 o Implementations MUST support and (unless a higher version is 267 available) MUST prefer to negotiate DTLS version 1.2 [RFC6347] 269 Version 1.2 of DTLS correlates to version 1.2 of TLS (see above). 270 (There is no version 1.1 of DTLS.) 272 o Implementations SHOULD support and, if available, MUST prefer to 273 negotiate DTLS version 1.3 as specified in [I-D.ietf-tls-dtls13]. 275 Version 1.3 of DTLS correlates to version 1.3 of TLS (see above). 277 3.1.3. Fallback to Lower Versions 279 Clients that "fall back" to lower versions of the protocol after the 280 server rejects higher versions of the protocol MUST NOT fall back to 281 SSLv3 or earlier. Implementations of TLS/DTLS 1.2 or earlier MUST 282 implement the Fallback SCSV mechanism [RFC7507] to prevent such 283 fallback being forced by an attacker. 285 Rationale: Some client implementations revert to lower versions of 286 TLS or even to SSLv3 if the server rejected higher versions of the 287 protocol. This fallback can be forced by a man-in-the-middle (MITM) 288 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 289 1.2 but at least TLS 1.0 is still allowed by many web servers. As of 290 this writing, the Fallback SCSV solution is widely deployed and 291 proven as a robust solution to this problem. 293 3.2. Strict TLS 295 The following recommendations are provided to help prevent SSL 296 Stripping (an attack that is summarized in Section 2.1 of [RFC7457]): 298 o In cases where an application protocol allows implementations or 299 deployments a choice between strict TLS configuration and dynamic 300 upgrade from unencrypted to TLS-protected traffic (such as 301 STARTTLS), clients and servers SHOULD prefer strict TLS 302 configuration. 303 o Application protocols typically provide a way for the server to 304 offer TLS during an initial protocol exchange, and sometimes also 305 provide a way for the server to advertise support for TLS (e.g., 306 through a flag indicating that TLS is required); unfortunately, 307 these indications are sent before the communication channel is 308 encrypted. A client SHOULD attempt to negotiate TLS even if these 309 indications are not communicated by the server. 310 o HTTP client and server implementations MUST support the HTTP 311 Strict Transport Security (HSTS) header [RFC6797], in order to 312 allow Web servers to advertise that they are willing to accept 313 TLS-only clients. 314 o Web servers SHOULD use HSTS to indicate that they are willing to 315 accept TLS-only clients, unless they are deployed in such a way 316 that using HSTS would in fact weaken overall security (e.g., it 317 can be problematic to use HSTS with self-signed certificates, as 318 described in Section 11.3 of [RFC6797]). 320 Rationale: Combining unprotected and TLS-protected communication 321 opens the way to SSL Stripping and similar attacks, since an initial 322 part of the communication is not integrity protected and therefore 323 can be manipulated by an attacker whose goal is to keep the 324 communication in the clear. 326 3.3. Compression 328 In order to help prevent compression-related attacks (summarized in 329 Section 2.6 of [RFC7457]), when using TLS 1.2 implementations and 330 deployments SHOULD disable TLS-level compression (Section 6.2.2 of 331 [RFC5246]), unless the application protocol in question has been 332 shown not to be open to such attacks. Note: this recommendation 333 applies to TLS 1.2 only, because compression has been removed from 334 TLS 1.3. 336 Rationale: TLS compression has been subject to security attacks, such 337 as the CRIME attack. 339 Implementers should note that compression at higher protocol levels 340 can allow an active attacker to extract cleartext information from 341 the connection. The BREACH attack is one such case. These issues 342 can only be mitigated outside of TLS and are thus outside the scope 343 of this document. See Section 2.6 of [RFC7457] for further details. 345 3.4. TLS Session Resumption 347 If TLS session resumption is used in the context of TLS 1.2, care 348 ought to be taken to do so safely. In particular, when using session 349 tickets [RFC5077], the resumption information MUST be authenticated 350 and encrypted to prevent modification or eavesdropping by an 351 attacker. Further recommendations apply to session tickets: 353 o A strong cipher suite MUST be used when encrypting the ticket (as 354 least as strong as the main TLS cipher suite). 355 o Ticket keys MUST be changed regularly, e.g., once every week, so 356 as not to negate the benefits of forward secrecy (see Section 6.2 357 for details on forward secrecy). 358 o For similar reasons, session ticket validity SHOULD be limited to 359 a reasonable duration (e.g., half as long as ticket key validity). 361 Rationale: session resumption is another kind of TLS handshake, and 362 therefore must be as secure as the initial handshake. This document 363 (Section 4) recommends the use of cipher suites that provide forward 364 secrecy, i.e. that prevent an attacker who gains momentary access to 365 the TLS endpoint (either client or server) and its secrets from 366 reading either past or future communication. The tickets must be 367 managed so as not to negate this security property. 369 3.5. TLS Renegotiation 371 Where handshake renegotiation is implemented, both clients and 372 servers MUST implement the renegotiation_info extension, as defined 373 in [RFC5746]. Note: this recommendation applies to TLS 1.2 only, 374 because renegotiation has been removed from TLS 1.3. 376 The most secure option for countering the Triple Handshake attack is 377 to refuse any change of certificates during renegotiation. In 378 addition, TLS clients SHOULD apply the same validation policy for all 379 certificates received over a connection. The [triple-handshake] 380 document suggests several other possible countermeasures, such as 381 binding the master secret to the full handshake (see [SESSION-HASH]) 382 and binding the abbreviated session resumption handshake to the 383 original full handshake. Although the latter two techniques are 384 still under development and thus do not qualify as current practices, 385 those who implement and deploy TLS are advised to watch for further 386 development of appropriate countermeasures. 388 3.6. Server Name Indication 390 TLS implementations MUST support the Server Name Indication (SNI) 391 extension defined in Section 3 of [RFC6066] for those higher-level 392 protocols that would benefit from it, including HTTPS. However, the 393 actual use of SNI in particular circumstances is a matter of local 394 policy. Implementers are strongly encouraged to support TLS 395 Encrypted Client Hello (formerly called Encrypted SNI) once 396 [I-D.ietf-tls-esni] has been standardized. 398 Rationale: SNI supports deployment of multiple TLS-protected virtual 399 servers on a single address, and therefore enables fine-grained 400 security for these virtual servers, by allowing each one to have its 401 own certificate. However, SNI also leaks the target domain for a 402 given connection; this information leak will be plugged by use of TLS 403 Encrypted Client Hello. 405 4. Recommendations: Cipher Suites 407 TLS and its implementations provide considerable flexibility in the 408 selection of cipher suites. Unfortunately, some available cipher 409 suites are insecure, some do not provide the targeted security 410 services, and some no longer provide enough security. Incorrectly 411 configuring a server leads to no or reduced security. This section 412 includes recommendations on the selection and negotiation of cipher 413 suites. 415 4.1. General Guidelines 417 Cryptographic algorithms weaken over time as cryptanalysis improves: 418 algorithms that were once considered strong become weak. Such 419 algorithms need to be phased out over time and replaced with more 420 secure cipher suites. This helps to ensure that the desired security 421 properties still hold. SSL/TLS has been in existence for almost 20 422 years and many of the cipher suites that have been recommended in 423 various versions of SSL/TLS are now considered weak or at least not 424 as strong as desired. Therefore, this section modernizes the 425 recommendations concerning cipher suite selection. 427 o Implementations MUST NOT negotiate the cipher suites with NULL 428 encryption. 430 Rationale: The NULL cipher suites do not encrypt traffic and so 431 provide no confidentiality services. Any entity in the network 432 with access to the connection can view the plaintext of contents 433 being exchanged by the client and server. 434 (Nevertheless, this document does not discourage software from 435 implementing NULL cipher suites, since they can be useful for 436 testing and debugging.) 437 o Implementations MUST NOT negotiate RC4 cipher suites. 439 Rationale: The RC4 stream cipher has a variety of cryptographic 440 weaknesses, as documented in [RFC7465]. Note that DTLS 441 specifically forbids the use of RC4 already. 442 o Implementations MUST NOT negotiate cipher suites offering less 443 than 112 bits of security, including so-called "export-level" 444 encryption (which provide 40 or 56 bits of security). 446 Rationale: Based on [RFC3766], at least 112 bits of security is 447 needed. 40-bit and 56-bit security are considered insecure today. 448 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. 449 o Implementations SHOULD NOT negotiate cipher suites that use 450 algorithms offering less than 128 bits of security. 452 Rationale: Cipher suites that offer between 112-bits and 128-bits 453 of security are not considered weak at this time; however, it is 454 expected that their useful lifespan is short enough to justify 455 supporting stronger cipher suites at this time. 128-bit ciphers 456 are expected to remain secure for at least several years, and 457 256-bit ciphers until the next fundamental technology 458 breakthrough. Note that, because of so-called "meet-in-the- 459 middle" attacks [Multiple-Encryption], some legacy cipher suites 460 (e.g., 168-bit 3DES) have an effective key length that is smaller 461 than their nominal key length (112 bits in the case of 3DES). 462 Such cipher suites should be evaluated according to their 463 effective key length. 464 o Implementations SHOULD NOT negotiate cipher suites based on RSA 465 key transport, a.k.a. "static RSA". 467 Rationale: These cipher suites, which have assigned values 468 starting with the string "TLS_RSA_WITH_*", have several drawbacks, 469 especially the fact that they do not support forward secrecy. 470 o Implementations MUST support and prefer to negotiate cipher suites 471 offering forward secrecy, such as those in the Ephemeral Diffie- 472 Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and 473 "ECDHE") families. 475 Rationale: Forward secrecy (sometimes called "perfect forward 476 secrecy") prevents the recovery of information that was encrypted 477 with older session keys, thus limiting the amount of time during 478 which attacks can be successful. See Section 6.2 for a detailed 479 discussion. 481 4.2. Recommended Cipher Suites 483 Given the foregoing considerations, implementation and deployment of 484 the following cipher suites is RECOMMENDED: 486 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 487 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 488 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 489 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 491 These cipher suites are supported only in TLS 1.2 because they are 492 authenticated encryption (AEAD) algorithms [RFC5116]. 494 Typically, in order to prefer these suites, the order of suites needs 495 to be explicitly configured in server software. (See [BETTERCRYPTO] 496 for helpful deployment guidelines, but note that its recommendations 497 differ from the current document in some details.) It would be ideal 498 if server software implementations were to prefer these suites by 499 default. 501 Some devices have hardware support for AES-CCM but not AES-GCM, so 502 they are unable to follow the foregoing recommendations regarding 503 cipher suites. There are even devices that do not support public key 504 cryptography at all, but they are out of scope entirely. 506 4.2.1. Implementation Details 508 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 509 first proposal to any server, unless they have prior knowledge that 510 the server cannot respond to a TLS 1.2 client_hello message. 512 Servers MUST prefer this cipher suite over weaker cipher suites 513 whenever it is proposed, even if it is not the first proposal. 515 Clients are of course free to offer stronger cipher suites, e.g., 516 using AES-256; when they do, the server SHOULD prefer the stronger 517 cipher suite unless there are compelling reasons (e.g., seriously 518 degraded performance) to choose otherwise. 520 This document does not change the mandatory-to-implement TLS cipher 521 suite(s) prescribed by TLS. To maximize interoperability, RFC 5246 522 mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher 523 suite, which is significantly weaker than the cipher suites 524 recommended here. (The GCM mode does not suffer from the same 525 weakness, caused by the order of MAC-then-Encrypt in TLS 527 [Krawczyk2001], since it uses an AEAD mode of operation.) 528 Implementers should consider the interoperability gain against the 529 loss in security when deploying the TLS_RSA_WITH_AES_128_CBC_SHA 530 cipher suite. Other application protocols specify other cipher 531 suites as mandatory to implement (MTI). 533 Note that some profiles of TLS 1.2 use different cipher suites. For 534 example, [RFC6460] defines a profile that uses the 535 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 536 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 538 [RFC4492] allows clients and servers to negotiate ECDH parameters 539 (curves). Both clients and servers SHOULD include the "Supported 540 Elliptic Curves" extension [RFC4492]. For interoperability, clients 541 and servers SHOULD support the NIST P-256 (secp256r1) curve 542 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 543 extension with a single element, "uncompressed". 545 4.3. Public Key Length 547 When using the cipher suites recommended in this document, two public 548 keys are normally used in the TLS handshake: one for the Diffie- 549 Hellman key agreement and one for server authentication. Where a 550 client certificate is used, a third public key is added. 552 With a key exchange based on modular exponential (MODP) Diffie- 553 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 554 bits are RECOMMENDED. 556 Rationale: For various reasons, in practice, DH keys are typically 557 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 558 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 559 would be roughly equivalent to only an 80-bit symmetric key 560 [RFC3766], it is better to use keys longer than that for the "DHE" 561 family of cipher suites. A DH key of 1926 bits would be roughly 562 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 563 bits might be sufficient for at least the next 10 years 564 [NIST.SP.800-56A]. See Section 4.4 for additional information on the 565 use of MODP Diffie-Hellman in TLS. 567 As noted in [RFC3766], correcting for the emergence of a TWIRL 568 machine would imply that 1024-bit DH keys yield about 65 bits of 569 equivalent strength and that a 2048-bit DH key would yield about 92 570 bits of equivalent strength. 572 With regard to ECDH keys, the IANA "EC Named Curve Registry" (within 573 the "Transport Layer Security (TLS) Parameters" registry [IANA_TLS]) 574 contains 160-bit elliptic curves that are considered to be roughly 575 equivalent to only an 80-bit symmetric key [ECRYPT-II]. Curves of 576 less than 192 bits SHOULD NOT be used. 578 When using RSA, servers SHOULD authenticate using certificates with 579 at least a 2048-bit modulus for the public key. In addition, the use 580 of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for 581 more details). Clients SHOULD indicate to servers that they request 582 SHA-256, by using the "Signature Algorithms" extension defined in TLS 583 1.2. 585 4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites 587 Not all TLS implementations support both modular exponential (MODP) 588 and elliptic curve (EC) Diffie-Hellman groups, as required by 589 Section 4.2. Some implementations are severely limited in the length 590 of DH values. When such implementations need to be accommodated, the 591 following are RECOMMENDED (in priority order): 593 1. Elliptic Curve DHE with appropriately negotiated parameters 594 (e.g., the curve to be used) and a Message Authentication Code 595 (MAC) algorithm stronger than HMAC-SHA1 [RFC5289] 596 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 597 Diffie-Hellman parameters 598 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters 600 Rationale: Although Elliptic Curve Cryptography is widely deployed, 601 there are some communities where its adoption has been limited for 602 several reasons, including its complexity compared to modular 603 arithmetic and longstanding perceptions of IPR concerns (which, for 604 the most part, have now been resolved [RFC6090]). Note that ECDHE 605 cipher suites exist for both RSA and ECDSA certificates, so moving to 606 ECDHE cipher suites does not require moving away from RSA-based 607 certificates. On the other hand, there are two related issues 608 hindering effective use of MODP Diffie-Hellman cipher suites in TLS: 610 o There are no standardized, widely implemented protocol mechanisms 611 to negotiate the DH groups or parameter lengths supported by 612 client and server. 613 o Many servers choose DH parameters of 1024 bits or fewer. 614 o There are widely deployed client implementations that reject 615 received DH parameters if they are longer than 1024 bits. In 616 addition, several implementations do not perform appropriate 617 validation of group parameters and are vulnerable to attacks 618 referenced in Section 2.9 of [RFC7457]. 620 Note that with DHE and ECDHE cipher suites, the TLS master key only 621 depends on the Diffie-Hellman parameters and not on the strength of 622 the RSA certificate; moreover, 1024 bit MODP DH parameters are 623 generally considered insufficient at this time. 625 With MODP ephemeral DH, deployers ought to carefully evaluate 626 interoperability vs. security considerations when configuring their 627 TLS endpoints. 629 4.5. Truncated HMAC 631 Implementations MUST NOT use the Truncated HMAC extension, defined in 632 Section 7 of [RFC6066]. 634 Rationale: the extension does not apply to the AEAD cipher suites 635 recommended above. However it does apply to most other TLS cipher 636 suites. Its use has been shown to be insecure in [PatersonRS11]. 638 5. Applicability Statement 640 The recommendations of this document primarily apply to the 641 implementation and deployment of application protocols that are most 642 commonly used with TLS and DTLS on the Internet today. Examples 643 include, but are not limited to: 645 o Web software and services that wish to protect HTTP traffic with 646 TLS. 647 o Email software and services that wish to protect IMAP, POP3, or 648 SMTP traffic with TLS. 649 o Instant-messaging software and services that wish to protect 650 Extensible Messaging and Presence Protocol (XMPP) or Internet 651 Relay Chat (IRC) traffic with TLS. 652 o Realtime media software and services that wish to protect Secure 653 Realtime Transport Protocol (SRTP) traffic with DTLS. 655 This document does not modify the implementation and deployment 656 recommendations (e.g., mandatory-to-implement cipher suites) 657 prescribed by existing application protocols that employ TLS or DTLS. 658 If the community that uses such an application protocol wishes to 659 modernize its usage of TLS or DTLS to be consistent with the best 660 practices recommended here, it needs to explicitly update the 661 existing application protocol definition (one example is [TLS-XMPP], 662 which updates [RFC6120]). 664 Designers of new application protocols developed through the Internet 665 Standards Process [RFC2026] are expected at minimum to conform to the 666 best practices recommended here, unless they provide documentation of 667 compelling reasons that would prevent such conformance (e.g., 668 widespread deployment on constrained devices that lack support for 669 the necessary algorithms). 671 5.1. Security Services 673 This document provides recommendations for an audience that wishes to 674 secure their communication with TLS to achieve the following: 676 o Confidentiality: all application-layer communication is encrypted 677 with the goal that no party should be able to decrypt it except 678 the intended receiver. 679 o Data integrity: any changes made to the communication in transit 680 are detectable by the receiver. 681 o Authentication: an endpoint of the TLS communication is 682 authenticated as the intended entity to communicate with. 684 With regard to authentication, TLS enables authentication of one or 685 both endpoints in the communication. In the context of opportunistic 686 security [RFC7435], TLS is sometimes used without authentication. As 687 discussed in Section 5.2, considerations for opportunistic security 688 are not in scope for this document. 690 If deployers deviate from the recommendations given in this document, 691 they need to be aware that they might lose access to one of the 692 foregoing security services. 694 This document applies only to environments where confidentiality is 695 required. It recommends algorithms and configuration options that 696 enforce secrecy of the data in transit. 698 This document also assumes that data integrity protection is always 699 one of the goals of a deployment. In cases where integrity is not 700 required, it does not make sense to employ TLS in the first place. 701 There are attacks against confidentiality-only protection that 702 utilize the lack of integrity to also break confidentiality (see, for 703 instance, [DegabrieleP07] in the context of IPsec). 705 This document addresses itself to application protocols that are most 706 commonly used on the Internet with TLS and DTLS. Typically, all 707 communication between TLS clients and TLS servers requires all three 708 of the above security services. This is particularly true where TLS 709 clients are user agents like Web browsers or email software. 711 This document does not address the rarer deployment scenarios where 712 one of the above three properties is not desired, such as the use 713 case described in Section 5.2 below. As another scenario where 714 confidentiality is not needed, consider a monitored network where the 715 authorities in charge of the respective traffic domain require full 716 access to unencrypted (plaintext) traffic, and where users 717 collaborate and send their traffic in the clear. 719 5.2. Opportunistic Security 721 There are several important scenarios in which the use of TLS is 722 optional, i.e., the client decides dynamically ("opportunistically") 723 whether to use TLS with a particular server or to connect in the 724 clear. This practice, often called "opportunistic security", is 725 described at length in [RFC7435] and is often motivated by a desire 726 for backward compatibility with legacy deployments. 728 In these scenarios, some of the recommendations in this document 729 might be too strict, since adhering to them could cause fallback to 730 cleartext, a worse outcome than using TLS with an outdated protocol 731 version or cipher suite. 733 This document specifies best practices for TLS in general. A 734 separate document containing recommendations for the use of TLS with 735 opportunistic security is to be completed in the future. 737 6. Security Considerations 739 This entire document discusses the security practices directly 740 affecting applications using the TLS protocol. This section contains 741 broader security considerations related to technologies used in 742 conjunction with or by TLS. ## Host Name Validation 744 Application authors should take note that some TLS implementations do 745 not validate host names. If the TLS implementation they are using 746 does not validate host names, authors might need to write their own 747 validation code or consider using a different TLS implementation. 749 It is noted that the requirements regarding host name validation 750 (and, in general, binding between the TLS layer and the protocol that 751 runs above it) vary between different protocols. For HTTPS, these 752 requirements are defined by Section 3 of [RFC2818]. 754 Readers are referred to [RFC6125] for further details regarding 755 generic host name validation in the TLS context. In addition, that 756 RFC contains a long list of example protocols, some of which 757 implement a policy very different from HTTPS. 759 If the host name is discovered indirectly and in an insecure manner 760 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 761 NOT be used as a reference identifier [RFC6125] even when it matches 762 the presented certificate. This proviso does not apply if the host 763 name is discovered securely (for further discussion, see [DANE-SRV] 764 and [DANE-SMTP]). 766 Host name validation typically applies only to the leaf "end entity" 767 certificate. Naturally, in order to ensure proper authentication in 768 the context of the PKI, application clients need to verify the entire 769 certification path in accordance with [RFC5280] (see also [RFC6125]). 771 6.1. AES-GCM 773 Section 4.2 above recommends the use of the AES-GCM authenticated 774 encryption algorithm. Please refer to Section 11 of [RFC5246] for 775 general security considerations when using TLS 1.2, and to Section 6 776 of [RFC5288] for security considerations that apply specifically to 777 AES-GCM when used with TLS. 779 6.2. Forward Secrecy 781 Forward secrecy (also called "perfect forward secrecy" or "PFS" and 782 defined in [RFC4949]) is a defense against an attacker who records 783 encrypted conversations where the session keys are only encrypted 784 with the communicating parties' long-term keys. 786 Should the attacker be able to obtain these long-term keys at some 787 point later in time, the session keys and thus the entire 788 conversation could be decrypted. 790 In the context of TLS and DTLS, such compromise of long-term keys is 791 not entirely implausible. It can happen, for example, due to: 793 o A client or server being attacked by some other attack vector, and 794 the private key retrieved. 795 o A long-term key retrieved from a device that has been sold or 796 otherwise decommissioned without prior wiping. 797 o A long-term key used on a device as a default key [Heninger2012]. 798 o A key generated by a trusted third party like a CA, and later 799 retrieved from it either by extortion or compromise 800 [Soghoian2011]. 801 o A cryptographic break-through, or the use of asymmetric keys with 802 insufficient length [Kleinjung2010]. 803 o Social engineering attacks against system administrators. 804 o Collection of private keys from inadequately protected backups. 806 Forward secrecy ensures in such cases that it is not feasible for an 807 attacker to determine the session keys even if the attacker has 808 obtained the long-term keys some time after the conversation. It 809 also protects against an attacker who is in possession of the long- 810 term keys but remains passive during the conversation. 812 Forward secrecy is generally achieved by using the Diffie-Hellman 813 scheme to derive session keys. The Diffie-Hellman scheme has both 814 parties maintain private secrets and send parameters over the network 815 as modular powers over certain cyclic groups. The properties of the 816 so-called Discrete Logarithm Problem (DLP) allow the parties to 817 derive the session keys without an eavesdropper being able to do so. 818 There is currently no known attack against DLP if sufficiently large 819 parameters are chosen. A variant of the Diffie-Hellman scheme uses 820 Elliptic Curves instead of the originally proposed modular 821 arithmetics. 823 Unfortunately, many TLS/DTLS cipher suites were defined that do not 824 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This 825 document therefore advocates strict use of forward-secrecy-only 826 ciphers. 828 6.3. Diffie-Hellman Exponent Reuse 830 For performance reasons, many TLS implementations reuse Diffie- 831 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 832 connections. Such reuse can result in major security issues: 834 o If exponents are reused for too long (e.g., even more than a few 835 hours), an attacker who gains access to the host can decrypt 836 previous connections. In other words, exponent reuse negates the 837 effects of forward secrecy. 838 o TLS implementations that reuse exponents should test the DH public 839 key they receive for group membership, in order to avoid some 840 known attacks. These tests are not standardized in TLS at the 841 time of writing. See [RFC6989] for recipient tests required of 842 IKEv2 implementations that reuse DH exponents. 844 6.4. Certificate Revocation 846 The following considerations and recommendations represent the 847 current state of the art regarding certificate revocation, even 848 though no complete and efficient solution exists for the problem of 849 checking the revocation status of common public key certificates 850 [RFC5280]: 852 o Although Certificate Revocation Lists (CRLs) are the most widely 853 supported mechanism for distributing revocation information, they 854 have known scaling challenges that limit their usefulness (despite 855 workarounds such as partitioned CRLs and delta CRLs). 856 o Proprietary mechanisms that embed revocation lists in the Web 857 browser's configuration database cannot scale beyond a small 858 number of the most heavily used Web servers. 859 o The On-Line Certification Status Protocol (OCSP) [RFC6960] 860 presents both scaling and privacy issues. In addition, clients 861 typically "soft-fail", meaning that they do not abort the TLS 862 connection if the OCSP server does not respond. (However, this 863 might be a workaround to avoid denial-of-service attacks if an 864 OCSP responder is taken offline.) 865 o The TLS Certificate Status Request extension (Section 8 of 866 [RFC6066]), commonly called "OCSP stapling", resolves the 867 operational issues with OCSP. However, it is still ineffective in 868 the presence of a MITM attacker because the attacker can simply 869 ignore the client's request for a stapled OCSP response. 870 o OCSP stapling as defined in [RFC6066] does not extend to 871 intermediate certificates used in a certificate chain. Although 872 the Multiple Certificate Status extension [RFC6961] addresses this 873 shortcoming, it is a recent addition without much deployment. 874 o Both CRLs and OCSP depend on relatively reliable connectivity to 875 the Internet, which might not be available to certain kinds of 876 nodes (such as newly provisioned devices that need to establish a 877 secure connection in order to boot up for the first time). 879 With regard to common public key certificates, servers SHOULD support 880 the following as a best practice given the current state of the art 881 and as a foundation for a possible future solution: 883 1. OCSP [RFC6960] 884 2. Both the status_request extension defined in [RFC6066] and the 885 status_request_v2 extension defined in [RFC6961] (This might 886 enable interoperability with the widest range of clients.) 887 3. The OCSP stapling extension defined in [RFC6961] 889 The considerations in this section do not apply to scenarios where 890 the DANE-TLSA resource record [RFC6698] is used to signal to a client 891 which certificate a server considers valid and good to use for TLS 892 connections. 894 7. Acknowledgments 896 The following acknowledgements are inherited from [RFC7525]. 898 Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen 899 Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson 900 Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, 901 Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom 902 Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean 903 Turner, and Aaron Zauner for their feedback and suggested 904 improvements. Thanks also to Brian Smith, who has provided a great 905 resource in his "Proposal to Change the Default TLS Ciphersuites 906 Offered by Browsers" [Smith2013]. Finally, thanks to all others who 907 commented on the TLS, UTA, and other discussion lists but who are not 908 mentioned here by name. 910 Robert Sparks and Dave Waltermire provided helpful reviews on behalf 911 of the General Area Review Team and the Security Directorate, 912 respectively. 914 During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins, 915 Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick 916 provided comments that led to further improvements. 918 Ralph Holz gratefully acknowledges the support by Technische 919 Universitaet Muenchen. 921 The authors gratefully acknowledge the assistance of Leif Johansson 922 and Orit Levin as the working group chairs and Pete Resnick as the 923 sponsoring Area Director. 925 8. References 927 8.1. Normative References 929 [I-D.ietf-tls-dtls13] 930 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 931 Datagram Transport Layer Security (DTLS) Protocol Version 932 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 933 2020. 935 [I-D.ietf-tls-oldversions-deprecate] 936 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 937 TLSv1.1", draft-ietf-tls-oldversions-deprecate-08 (work in 938 progress), October 2020. 940 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 941 Requirement Levels", BCP 14, RFC 2119, 942 DOI 10.17487/RFC2119, March 1997, 943 . 945 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 946 DOI 10.17487/RFC2818, May 2000, 947 . 949 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 950 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 951 RFC 3766, DOI 10.17487/RFC3766, April 2004, 952 . 954 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 955 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 956 for Transport Layer Security (TLS)", RFC 4492, 957 DOI 10.17487/RFC4492, May 2006, 958 . 960 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 961 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 962 . 964 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 965 (TLS) Protocol Version 1.2", RFC 5246, 966 DOI 10.17487/RFC5246, August 2008, 967 . 969 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 970 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 971 DOI 10.17487/RFC5288, August 2008, 972 . 974 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 975 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 976 DOI 10.17487/RFC5289, August 2008, 977 . 979 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 980 "Transport Layer Security (TLS) Renegotiation Indication 981 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 982 . 984 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 985 Extensions: Extension Definitions", RFC 6066, 986 DOI 10.17487/RFC6066, January 2011, 987 . 989 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 990 Verification of Domain-Based Application Service Identity 991 within Internet Public Key Infrastructure Using X.509 992 (PKIX) Certificates in the Context of Transport Layer 993 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 994 2011, . 996 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 997 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 998 2011, . 1000 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1001 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1002 January 2012, . 1004 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 1005 DOI 10.17487/RFC7465, February 2015, 1006 . 1008 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1009 Suite Value (SCSV) for Preventing Protocol Downgrade 1010 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 1011 . 1013 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1014 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1015 May 2017, . 1017 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1018 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1019 . 1021 8.2. Informative References 1023 [BETTERCRYPTO] 1024 bettercrypto.org, "Applied Crypto Hardening", April 2015, 1025 . 1028 [CAB-Baseline] 1029 CA/Browser Forum, "Baseline Requirements for the Issuance 1030 and Management of Publicly-Trusted Certificates Version 1031 1.1.6", 2013, . 1033 [DANE-SMTP] 1034 Dukhovni, V. and W. Hardaker, "SMTP Security via 1035 Opportunistic DNS-Based Authentication of Named Entities 1036 (DANE) Transport Layer Security (TLS)", RFC 7672, 1037 DOI 10.17487/RFC7672, October 2015, 1038 . 1040 [DANE-SRV] 1041 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1042 Based Authentication of Named Entities (DANE) TLSA Records 1043 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1044 2015, . 1046 [DegabrieleP07] 1047 Degabriele, J. and K. Paterson, "Attacking the IPsec 1048 Standards in Encryption-only Configurations", 2007 IEEE 1049 Symposium on Security and Privacy (SP '07), 1050 DOI 10.1109/sp.2007.8, May 2007. 1052 [DEP-SSLv3] 1053 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 1054 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 1055 DOI 10.17487/RFC7568, June 2015, 1056 . 1058 [ECRYPT-II] 1059 Smart, N., "ECRYPT II Yearly Report on Algorithms and 1060 Keysizes (2011-2012)", 2012, 1061 . 1063 [Heninger2012] 1064 Heninger, N., Durumeric, Z., Wustrow, E., and J. 1065 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1066 Weak Keys in Network Devices", Usenix Security 1067 Symposium 2012, 2012. 1069 [I-D.ietf-quic-tls] 1070 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 1071 draft-ietf-quic-tls-32 (work in progress), October 2020. 1073 [I-D.ietf-tls-esni] 1074 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1075 Encrypted Client Hello", draft-ietf-tls-esni-08 (work in 1076 progress), October 2020. 1078 [IANA_TLS] 1079 IANA, "Transport Layer Security (TLS) Parameters", 1080 . 1082 [Kleinjung2010] 1083 Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thome, 1084 E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P., 1085 Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann, 1086 "Factorization of a 768-Bit RSA Modulus", Advances in 1087 Cryptology - CRYPTO 2010 pp. 333-350, 1088 DOI 10.1007/978-3-642-14623-7_18, 2010. 1090 [Krawczyk2001] 1091 Krawczyk, H., "The Order of Encryption and Authentication 1092 for Protecting Communications (Or: How Secure is SSL?)", 1093 CRYPTO 01, 2001, 1094 . 1096 [Multiple-Encryption] 1097 Merkle, R. and M. Hellman, "On the security of multiple 1098 encryption", Communications of the ACM Vol. 24, pp. 1099 465-467, DOI 10.1145/358699.358718, July 1981. 1101 [NIST.SP.800-56A] 1102 Barker, E., Chen, L., Roginsky, A., and M. Smid, 1103 "Recommendation for Pair-Wise Key Establishment Schemes 1104 Using Discrete Logarithm Cryptography", NIST Special 1105 Publication 800-56A, 2013, 1106 . 1109 [PatersonRS11] 1110 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size 1111 Does Matter: Attacks and Proofs for the TLS Record 1112 Protocol", Lecture Notes in Computer Science pp. 372-389, 1113 DOI 10.1007/978-3-642-25385-0_20, 2011. 1115 [POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE 1116 Attack", October 2014, 1117 . 1119 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1120 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1121 . 1123 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1124 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1125 . 1127 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1128 Algorithm and Its Use with IPsec", RFC 3602, 1129 DOI 10.17487/RFC3602, September 2003, 1130 . 1132 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1133 (TLS) Protocol Version 1.1", RFC 4346, 1134 DOI 10.17487/RFC4346, April 2006, 1135 . 1137 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1138 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1139 . 1141 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1142 "Transport Layer Security (TLS) Session Resumption without 1143 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1144 January 2008, . 1146 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1147 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1148 . 1150 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1151 Housley, R., and W. Polk, "Internet X.509 Public Key 1152 Infrastructure Certificate and Certificate Revocation List 1153 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1154 . 1156 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1157 Curve Cryptography Algorithms", RFC 6090, 1158 DOI 10.17487/RFC6090, February 2011, 1159 . 1161 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1162 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1163 DOI 10.17487/RFC6101, August 2011, 1164 . 1166 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1167 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1168 March 2011, . 1170 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1171 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 1172 January 2012, . 1174 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1175 of Named Entities (DANE) Transport Layer Security (TLS) 1176 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1177 2012, . 1179 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1180 Transport Security (HSTS)", RFC 6797, 1181 DOI 10.17487/RFC6797, November 2012, 1182 . 1184 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1185 Galperin, S., and C. Adams, "X.509 Internet Public Key 1186 Infrastructure Online Certificate Status Protocol - OCSP", 1187 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1188 . 1190 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1191 Multiple Certificate Status Request Extension", RFC 6961, 1192 DOI 10.17487/RFC6961, June 2013, 1193 . 1195 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 1196 Tests for the Internet Key Exchange Protocol Version 2 1197 (IKEv2)", RFC 6989, DOI 10.17487/RFC6989, July 2013, 1198 . 1200 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1201 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1202 December 2014, . 1204 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1205 Known Attacks on Transport Layer Security (TLS) and 1206 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1207 February 2015, . 1209 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1210 "Recommendations for Secure Use of Transport Layer 1211 Security (TLS) and Datagram Transport Layer Security 1212 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1213 2015, . 1215 [SESSION-HASH] 1216 Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1217 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1218 Session Hash and Extended Master Secret Extension", 1219 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1220 . 1222 [Smith2013] 1223 Smith, B., "Proposal to Change the Default TLS 1224 Ciphersuites Offered by Browsers.", 2013, 1225 . 1227 [Soghoian2011] 1228 Soghoian, C. and S. Stamm, "Certified Lies: Detecting and 1229 Defeating Government Interception Attacks Against SSL", 1230 SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010. 1232 [TLS-XMPP] 1233 Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 1234 Security (TLS) in the Extensible Messaging and Presence 1235 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 1236 2015, . 1238 [triple-handshake] 1239 Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and 1240 P. Strub, "Triple Handshakes and Cookie Cutters: Breaking 1241 and Fixing Authentication over TLS", 2014 IEEE Symposium 1242 on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014. 1244 Appendix A. Differences from RFC 7525 1246 o Clarified some items (e.g. renegotiation) that only apply to TLS 1247 1.2 - many more TBD. 1248 o Changed status of TLS 1.0 and 1.1 from SHOULD NOT to MUST NOT. 1249 o Added TLS 1.3 at a SHOULD level. 1250 o Similar changes to DTLS, pending publication of DTLS 1.3. 1251 o Fallback SCSV as a MUST for TLS 1.2. 1252 o Added mention of TLS Encrypted Client Hello, but no recommendation 1253 to use yet. 1255 Appendix B. Document History 1257 [[Note to RFC Editor: please remove before publication.]] 1259 B.1. draft-ietf-uta-rfc7525bis-00 1261 o Renamed: WG document. 1262 o Started populating list of changes from RFC 7525. 1263 o General rewording of abstract and intro for revised version. 1264 o Protocol versions, fallback. 1265 o Reference to ECHO. 1267 B.2. draft-sheffer-uta-rfc7525bis-00 1269 o Renamed, since the BCP number does not change. 1270 o Added an empty "Differences from RFC 7525" section. 1272 B.3. draft-sheffer-uta-bcp195bis-00 1274 o Initial release, the RFC 7525 text as-is, with some minor 1275 editorial changes to the references. 1277 Authors' Addresses 1279 Yaron Sheffer 1280 Intuit 1282 EMail: yaronf.ietf@gmail.com 1284 Ralph Holz 1285 University of Twente 1287 EMail: ralph.ietf@gmail.com 1288 Peter Saint-Andre 1289 Mozilla 1291 EMail: stpeter@mozilla.com