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