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