idnits 2.17.1 draft-ietf-uta-tls-bcp-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2015) is 3355 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) ** 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) == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-10 == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-06 == Outdated reference: A later version (-05) exists of draft-ietf-tls-downgrade-scsv-02 -- 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) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Y. Sheffer 3 Internet-Draft Porticor 4 Intended status: Best Current Practice R. Holz 5 Expires: August 15, 2015 TUM 6 P. Saint-Andre 7 &yet 8 February 11, 2015 10 Recommendations for Secure Use of TLS and DTLS 11 draft-ietf-uta-tls-bcp-09 13 Abstract 15 Transport Layer Security (TLS) and Datagram Transport Layer Security 16 (DTLS) are widely used to protect data exchanged over application 17 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the 18 last few years, several serious attacks on TLS have emerged, 19 including attacks on its most commonly used cipher suites and modes 20 of operation. This document provides recommendations for improving 21 the security of deployed services that use TLS and DTLS. The 22 recommendations are applicable to the majority of use cases. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 15, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 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 . . . . . . . . . . . . . 6 65 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 10 73 4.2.1. Implementation Details . . . . . . . . . . . . . . . 10 74 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 11 75 4.4. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 12 76 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 13 77 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 13 78 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Unauthenticated TLS and Opportunistic Security . . . . . 14 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 15 83 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 16 85 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 17 86 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 18 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 9.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 92 A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 24 93 A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 24 94 A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 24 95 A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 24 96 A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 24 97 A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 24 98 A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 25 99 A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 25 100 A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 25 101 A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 25 102 A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 26 103 A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 106 1. Introduction 108 Transport Layer Security (TLS) [RFC5246] and Datagram Transport 109 Security Layer (DTLS) [RFC6347] are widely used to protect data 110 exchanged over application protocols such as HTTP, SMTP, IMAP, POP, 111 SIP, and XMPP. Over the last few years, several serious attacks on 112 TLS have emerged, including attacks on its most commonly used cipher 113 suites and modes of operation. For instance, both the AES-CBC 114 [RFC3602] and RC4 [I-D.ietf-tls-prohibiting-rc4] encryption 115 algorithms, which together are the most widely deployed ciphers, have 116 been attacked in the context of TLS. A companion document [RFC7457] 117 provides detailed information about these attacks. 119 Because of these attacks, those who implement and deploy TLS and DTLS 120 need updated guidance on how TLS can be used securely. This document 121 provides guidance for deployed services as well as for software 122 implementations, assuming the implementer expects his or her code to 123 be deployed in environments defined in the following section. In 124 fact, this document calls for the deployment of algorithms that are 125 widely implemented but not yet widely deployed. Concerning 126 deployment, this document targets a wide audience, namely all 127 deployers who wish to add authentication (be it one-way only or 128 mutual), confidentiality, and data integrity protection to their 129 communications. 131 The recommendations herein take into consideration the security of 132 various mechanisms, their technical maturity and interoperability, 133 and their prevalence in implementations at the time of writing. 134 Unless it is explicitly called out that a recommendation applies to 135 TLS alone or to DTLS alone, each recommendation applies to both TLS 136 and DTLS. 138 It is expected that the TLS 1.3 specification will resolve many of 139 the vulnerabilities listed in this document. A system that deploys 140 TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or below. This 141 document is likely to be updated after TLS 1.3 gets noticeable 142 deployment. 144 These are minimum recommendations for the use of TLS in the vast 145 majority of implementation and deployment scenarios, with the 146 exception of unauthenticated TLS (see Section 5). Other 147 specifications that reference this document can have stricter 148 requirements related to one or more aspects of the protocol, based on 149 their particular circumstances (e.g., for use with a particular 150 application protocol); when that is the case, implementers are 151 advised to adhere to those stricter requirements. Furthermore, this 152 document provides a floor, not a ceiling, so stronger options are 153 always allowed (e.g., depending on differing evaluations of the 154 importance of cryptographic strength vs. computational load). 156 Community knowledge about the strength of various algorithms and 157 feasible attacks can change quickly, and experience shows that a 158 security BCP is a point-in-time statement. Readers are advised to 159 seek out any errata or updates that apply to this document. 161 2. Terminology 163 A number of security-related terms in this document are used in the 164 sense defined in [RFC4949]. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 3. General Recommendations 172 This section provides general recommendations on the secure use of 173 TLS. Recommendations related to cipher suites are discussed in the 174 following section. 176 3.1. Protocol Versions 178 3.1.1. SSL/TLS Protocol Versions 180 It is important both to stop using old, less secure versions of SSL/ 181 TLS and to start using modern, more secure versions; therefore, the 182 following are the recommendations concerning TLS/SSL protocol 183 versions: 185 o Implementations MUST NOT negotiate SSL version 2. 187 Rationale: Today, SSLv2 is considered insecure [RFC6176]. 189 o Implementations MUST NOT negotiate SSL version 3. 191 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and 192 plugged some significant security holes, but did not support 193 strong cipher suites. SSLv3 does not support TLS extensions, some 194 of which (e.g., renegotiation_info) are security-critical. In 195 addition, with the emergence of the POODLE attack [POODLE], SSLv3 196 is now widely recognized as fundamentally insecure. 198 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. 200 Rationale: TLS 1.0 (published in 1999) does not support many 201 modern, strong cipher suites. In addition, TLS 1.0 lacks a per- 202 record IV for CBC-based cipher suites and does not warn against 203 common padding errors. 205 o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]. 207 Rationale: TLS 1.1 (published in 2006) is a security improvement 208 over TLS 1.0, but still does not support certain stronger cipher 209 suites. 211 o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to 212 negotiate TLS version 1.2 over earlier versions of TLS. 214 Rationale: Several stronger cipher suites are available only with 215 TLS 1.2 (published in 2008). In fact, the cipher suites 216 recommended by this document (Section 4.2 below) are only 217 available in TLS 1.2. 219 This BCP applies to TLS 1.2, and also to earlier versions. It is not 220 safe for readers to assume that the recommendations in this BCP apply 221 to any future version of TLS. 223 3.1.2. DTLS Protocol Versions 225 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 226 1.1 was published. The following are the recommendations with 227 respect to DTLS: 229 o Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347]. 231 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). 233 o Implementations MUST support, and prefer to negotiate, DTLS 234 version 1.2 [RFC6347]. 236 Version 1.2 of DTLS correlates to Version 1.2 of TLS 1.2 (see 237 above). (There is no Version 1.1 of DTLS.) 239 3.1.3. Fallback to Lower Versions 241 Clients that "fall back" to lower versions of the protocol after the 242 server rejects higher versions of the protocol MUST NOT fall back to 243 SSLv3 or earlier. 245 Rationale: Some client implementations revert to lower versions of 246 TLS or even to SSLv3 if the server rejected higher versions of the 247 protocol. This fallback can be forced by a man in the middle (MITM) 248 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 249 1.2, the version recommended by this document. While TLS 1.0-only 250 servers are still quite common, IP scans show that SSLv3-only servers 251 amount to only about 3% of the current Web server population. (At 252 the time of this writing, an explicit method for preventing downgrade 253 attacks is being defined in [I-D.ietf-tls-downgrade-scsv].) 255 3.2. Strict TLS 257 To prevent SSL Stripping: 259 o In cases where an application protocol allows implementations or 260 deployments a choice between strict TLS configuration and dynamic 261 upgrade from unencrypted to TLS-protected traffic (such as 262 STARTTLS), clients and servers SHOULD prefer strict TLS 263 configuration. 265 o Application protocols typically provide a way for the server to 266 offer TLS during an initial protocol exchange, and sometimes also 267 provide a way for the server to advertise support for TLS (e.g., 268 through a flag indicating that TLS is required); unfortunately, 269 these indications are sent before the communication channel is 270 encrypted. A client SHOULD attempt to negotiate TLS even if these 271 indications are not communicated by the server. 273 o HTTP client and server implementations MUST support the HTTP 274 Strict Transport Security (HSTS) header [RFC6797], in order to 275 allow Web servers to advertise that they are willing to accept 276 TLS-only clients. 278 o When applicable, Web servers SHOULD use HSTS to indicate that they 279 are willing to accept TLS-only clients. 281 Rationale: Combining unprotected and TLS-protected communication 282 opens the way to SSL Stripping and similar attacks, since an initial 283 part of the communication is not integrity protected and therefore 284 can be manipulated by an attacker whose goal is to keep the 285 communication in the clear. 287 3.3. Compression 289 Implementations and deployments SHOULD disable TLS-level compression 290 ([RFC5246], Section 6.2.2). 292 Rationale: TLS compression has been subject to security attacks, such 293 as the CRIME attack. 295 Implementers should note that compression at higher protocol levels 296 can allow an active attacker to extract cleartext information from 297 the connection. The BREACH attack is one such case. These issues 298 can only be mitigated outside of TLS and are thus out of scope of the 299 current document. See Section 2.6 of [RFC7457] for further details. 301 3.4. TLS Session Resumption 303 If TLS session resumption is used, care ought to be taken to do so 304 safely. In particular, when using session tickets [RFC5077], the 305 resumption information MUST be authenticated and encrypted to prevent 306 modification or eavesdropping by an attacker. Further 307 recommendations apply to session tickets: 309 o A strong cipher suite MUST be used when encrypting the ticket (as 310 least as strong as the main TLS cipher suite). 312 o Ticket keys MUST be changed regularly, e.g., once every week, so 313 as not to negate the benefits of forward secrecy (see Section 7.3 314 for details on forward secrecy). 316 o For similar reasons, session ticket validity SHOULD be limited to 317 a reasonable duration (e.g., half as long as ticket key validity). 319 Rationale: session resumption is another kind of TLS handshake, and 320 therefore must be as secure as the initial handshake. This document 321 (Section 4) recommends the use of cipher suites that provide forward 322 secrecy, i.e. that prevent an attacker who gains momentary access to 323 the TLS endpoint (either client or server) and its secrets from 324 reading either past or future communication. The tickets must be 325 managed so as not to negate this security property. 327 3.5. TLS Renegotiation 329 Where handshake renegotiation is implemented, both clients and 330 servers MUST implement the renegotiation_info extension, as defined 331 in [RFC5746]. 333 To counter the Triple Handshake attack, the recommended 334 countermeasures from [triple-handshake] are adopted: TLS clients 335 SHOULD apply the same validation policy for all certificates received 336 over a connection, bind the master secret to the full handshake, and 337 bind the abbreviated session resumption handshake to the original 338 full handshake. In some usages, the most secure option might be to 339 refuse any change of certificates during renegotiation. 341 3.6. Server Name Indication 343 TLS implementations MUST support the Server Name Indication (SNI) 344 extension for those higher level protocols which would benefit from 345 it, including HTTPS. However, unlike implementation, the use of SNI 346 in particular circumstances is a matter of local policy. 348 Rationale: SNI supports deployment of multiple TLS-protected virtual 349 servers on a single address, and therefore enables fine-grained 350 security for these virtual servers, by allowing each one to have its 351 own certificate. 353 4. Recommendations: Cipher Suites 355 TLS and its implementations provide considerable flexibility in the 356 selection of cipher suites. Unfortunately, some available cipher 357 suites are insecure, some do not provide the targeted security 358 services, and some no longer provide enough security. Incorrectly 359 configuring a server leads to no or reduced security. This section 360 includes recommendations on the selection and negotiation of cipher 361 suites. 363 4.1. General Guidelines 365 Cryptographic algorithms weaken over time as cryptanalysis improves: 366 algorithms that were once considered strong become weak. Such 367 algorithms need to be phased out over time and replaced with more 368 secure cipher suites. This helps to ensure that the desired security 369 properties still hold. SSL/TLS has been in existence for almost 20 370 years and many of the cipher suites that have been recommended in 371 various versions of SSL/TLS are now considered weak or at least not 372 as strong as desired. Therefore this section modernizes the 373 recommendations concerning cipher suite selection: 375 o Implementations MUST NOT negotiate the cipher suites with NULL 376 encryption. 378 Rationale: The NULL cipher suites do not encrypt traffic and so 379 provide no confidentiality services. Any entity in the network 380 with access to the connection can view the plaintext of contents 381 being exchanged by the client and server. (Nevertheless, this 382 document does not discourage software from implementing NULL 383 cipher suites, since they can be useful for testing and 384 debugging.) 386 o Implementations MUST NOT negotiate RC4 cipher suites. 388 Rationale: The RC4 stream cipher has a variety of cryptographic 389 weaknesses, as documented in [I-D.ietf-tls-prohibiting-rc4]. Note 390 that DTLS specifically forbids the use of RC4 already. 392 o Implementations MUST NOT negotiate cipher suites offering less 393 than 112 bits of security, including the so-called "export-level" 394 encryption (which provide 40 or 56 bits of security). 396 Rationale: Based on [RFC3766], at least 112 bits of security is 397 needed. 40-bit and 56-bit security are considered insecure today. 398 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 which 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. 416 o Implementations MUST support, and SHOULD prefer to negotiate, 417 cipher suites offering forward secrecy, such as those in the 418 Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie- 419 Hellman ("DHE" and "ECDHE") families. 421 Rationale: Forward secrecy (sometimes called "perfect forward 422 secrecy") prevents the recovery of information that was encrypted 423 with older session keys, thus limiting the amount of time during 424 which attacks can be successful. See Section 7.3 for a detailed 425 discussion. 427 4.2. Recommended Cipher Suites 429 Given the foregoing considerations, implementation and deployment of 430 the following cipher suites is RECOMMENDED: 432 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 434 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 436 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 438 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 440 These cipher suites are supported only in TLS 1.2 because they are 441 authenticated encryption (AEAD) algorithms [RFC5116]. 443 Typically, in order to prefer these suites, the order of suites needs 444 to be explicitly configured in server software. It would be ideal if 445 server software implementations were to prefer these suites by 446 default. 448 Some devices have hardware support for AES-CCM but not AES-GCM, so 449 they are unable to follow the foregoing recommendations regarding 450 cipher suites. There are even devices that do not support public key 451 cryptography at all, but they are out of scope entirely. 453 4.2.1. Implementation Details 455 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the 456 first proposal to any server, unless they have prior knowledge that 457 the server cannot respond to a TLS 1.2 client_hello message. 459 Servers SHOULD prefer this cipher suite over weaker cipher suites 460 whenever it is proposed, even if it is not the first proposal. 462 Clients are of course free to offer stronger cipher suites, e.g., 463 using AES-256; when they do, the server SHOULD prefer the stronger 464 cipher suite unless there are compelling reasons (e.g., seriously 465 degraded performance) to choose otherwise. 467 This document does not change the mandatory-to-implement TLS cipher 468 suite(s) prescribed by TLS or application protocols using TLS. To 469 maximize interoperability, RFC 5246 mandates implementation of the 470 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly 471 weaker than the cipher suites recommended here (the GCM mode does not 472 suffer from the same weakness, caused by the order of MAC-then- 473 Encrypt in TLS [Krawczyk2001], since it uses an Authenticated 474 Encryption with Associated Data (AEAD) mode of operation). 476 Implementers should consider the interoperability gain against the 477 loss in security when deploying that cipher suite. Other application 478 protocols specify other cipher suites as mandatory to implement 479 (MTI). 481 Note that some profiles of TLS 1.2 use different cipher suites. For 482 example, [RFC6460] defines a profile that uses the 483 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 484 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. 486 [RFC4492] allows clients and servers to negotiate ECDH parameters 487 (curves). Both clients and servers SHOULD include the "Supported 488 Elliptic Curves" extension [RFC4492]. For interoperability, clients 489 and servers SHOULD support the NIST P-256 (secp256r1) curve 490 [RFC4492]. In addition, clients SHOULD send an ec_point_formats 491 extension with a single element, "uncompressed". 493 4.3. Public Key Length 495 When using the cipher suites recommended in this document, two public 496 keys are normally used in the TLS handshake: one for the Diffie- 497 Hellman key agreement and one for server authentication. Where a 498 client certificate is used, a third public key is added. 500 With a key exchange based on modular Diffie-Hellman ("DHE" cipher 501 suites), DH key lengths of at least 2048 bits are RECOMMENDED. 503 Rationale: For various reasons, in practice DH keys are typically 504 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 505 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 506 would be roughly equivalent to only an 80-bit symmetric key 507 [RFC3766], it is better to use keys longer than that for the "DHE" 508 family of cipher suites. A DH key of 1926 bits would be roughly 509 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 510 bits might be sufficient for at least the next 10 years 511 [NIST.SP.800-56A]. See Section 4.4 for additional information on the 512 use of modular Diffie-Hellman in TLS. 514 As noted in [RFC3766], correcting for the emergence of a TWIRL 515 machine would imply that 1024-bit DH keys yield about 65 bits of 516 equivalent strength and that a 2048-bit DH key would yield about 92 517 bits of equivalent strength. 519 With regard to ECDH keys, the IANA named curve registry contains 520 160-bit elliptic curves which are considered to be roughly equivalent 521 to only an 80-bit symmetric key [ECRYPT-II]. Curves of less than 522 192-bits SHOULD NOT be used. 524 When using RSA servers SHOULD authenticate using certificates with at 525 least a 2048-bit modulus for the public key. In addition, the use of 526 the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for 527 more details). Clients SHOULD indicate to servers that they request 528 SHA-256, by using the "Signature Algorithms" extension defined in 529 TLS 1.2. 531 4.4. Modular vs. Elliptic Curve DH Cipher Suites 533 Not all TLS implementations support both modular and elliptic curve 534 Diffie-Hellman groups, as required by Section 4.2. Some 535 implementations are severely limited in the length of DH values. 536 When such implementations need to be accommodated, the following are 537 RECOMMENDED (in priority order): 539 1. Elliptic Curve DHE with negotiated parameters [RFC5289] 541 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 542 Diffie-Hellman parameters 544 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 546 Rationale: Although Elliptic Curve Cryptography is widely deployed 547 there are some communities where its uptake has been limited for 548 several reasons, including its complexity compared to modular 549 arithmetic and longstanding perceptions of IPR concerns (which, for 550 the most part, have now been resolved [RFC6090]). Note that ECDHE 551 cipher suites exist for both RSA and ECDSA certificates so moving to 552 ECDHE cipher suites does not require moving away from RSA based 553 certificates. On the other hand, there are two related issues 554 hindering effective use of modular Diffie-Hellman cipher suites in 555 TLS: 557 o There are no standardized, widely implemented protocol mechanisms 558 to negotiate the DH groups or parameter lengths supported by 559 client and server. 561 o Many servers choose DH parameters of 1024 bits or fewer. 563 o There are widely deployed client implementations that reject 564 received DH parameters if they are longer than 1024 bits. In 565 addition, several implementations do not perform appropriate 566 validation of group parameters and are vulnerable to attacks 567 referenced in Section 2.9 of [RFC7457] 569 Note that with DHE and ECDHE cipher suites, the TLS master key only 570 depends on the Diffie-Hellman parameters and not on the strength of 571 the RSA certificate; moreover, 1024 bit modular DH parameters are 572 generally considered insufficient at this time. 574 With modular ephemeral DH, deployers ought to carefully evaluate 575 interoperability vs. security considerations when configuring their 576 TLS endpoints. 578 4.5. Truncated HMAC 580 Implementations MUST NOT use the Truncated HMAC extension, defined in 581 Section 7 of [RFC6066]. 583 Rationale: the extension does not apply to the AEAD cipher suites 584 recommended above. However it does apply to most other TLS cipher 585 suites. Its use has been shown to be insecure in [PatersonRS11]. 587 5. Applicability Statement 589 The deployment recommendations of this document address the operators 590 of application layer services that are most commonly used on the 591 Internet, including, but not limited to: 593 o Operators of web services that wish to protect HTTP with TLS. 595 o Operators of email services who wish to protect the application- 596 layer protocols with TLS (e.g., IMAP, POP3 or SMTP). 598 o Operators of instant-messaging services who wish to protect their 599 application-layer protocols with TLS (e.g., XMPP or IRC). 601 5.1. Security Services 603 This document provides recommendations for an audience that wishes to 604 secure their communication with TLS to achieve the following: 606 o Confidentiality: all application-layer communication is encrypted 607 with the goal that no party should be able to decrypt it except 608 the intended receiver. 610 o Data integrity: any changes made to the communication in transit 611 are detectable by the receiver. 613 o Authentication: an end-point of the TLS communication is 614 authenticated as the intended entity to communicate with. 616 With regard to authentication, TLS enables authentication of one or 617 both end-points in the communication. Although some TLS usage 618 scenarios do not require authentication, those scenarios are not in 619 scope for this document (a rationale for this decision is provided 620 under Section 5.2). 622 If deployers deviate from the recommendations given in this document, 623 they need to be aware that they might lose access to one of the 624 foregoing security services. 626 This document applies only to environments where confidentiality is 627 required. It recommends algorithms and configuration options that 628 enforce secrecy of the data-in-transit. 630 This document also assumes that data integrity protection is always 631 one of the goals of a deployment. In cases where integrity is not 632 required, it does not make sense to employ TLS in the first place. 633 There are attacks against confidentiality-only protection that 634 utilize the lack of integrity to also break confidentiality (see for 635 instance [DegabrieleP07] in the context of IPsec). 637 This document addresses itself to application protocols that are most 638 commonly used on the Internet with TLS and DTLS. Typically, all 639 communication between TLS clients and TLS servers requires all three 640 of the above security services. This is particularly true where TLS 641 clients are user agents like Web browsers or email software. 643 This document does not address the rarer deployment scenarios where 644 one of the above three properties is not desired, such as the use 645 case described under Section 5.2 below. As another scenario where 646 confidentiality is not needed, consider a monitored network where the 647 authorities in charge of the respective traffic domain require full 648 access to unencrypted (plaintext) traffic, and where users 649 collaborate and send their traffic in the clear. 651 5.2. Unauthenticated TLS and Opportunistic Security 653 Several important applications use TLS to protect data between a TLS 654 client and a TLS server, but do so without the TLS client necessarily 655 verifying the server's certificate. This practice is often called 656 "unauthenticated TLS". The reader is referred to 657 [I-D.ietf-dane-smtp-with-dane] for an example and an explanation of 658 why this less secure practice will likely remain common in the 659 context of SMTP (especially for MTA-to-MTA communications). The 660 practice is also encountered in similar contexts such as server-to- 661 server traffic on the XMPP network (where multi-tenant hosting 662 environments make it difficult for operators to obtain proper 663 certificates for all of the domains they service). 665 Furthermore, in some scenarios the use of TLS itself is optional, 666 i.e. the client decides dynamically ("opportunistically") whether to 667 use TLS with a particular server or to connect in the clear. This 668 practice, often called "opportunistic security", is described at 669 length in [RFC7435]. 671 It can be argued that the recommendations provided in this document 672 ought to apply equally to unauthenticated TLS as well as 673 authenticated TLS. That would keep TLS implementations and 674 deployments in sync, which is a desirable property given that servers 675 can be used simultaneously for unauthenticated TLS and for 676 authenticated TLS (indeed, a server cannot know whether a client 677 might attempt authenticated or unauthenticated TLS). On the other 678 hand, it has been argued that some of the recommendations in this 679 document might be too strict for unauthenticated scenarios and that 680 any security is better than no security at all (i.e., sending traffic 681 in the clear), even if it means deploying outdated protocol versions 682 and ciphers in unauthenticated scenarios. The sense of the UTA 683 Working Group was to complete work on this document about 684 authenticated TLS and to initiate work on a separate document about 685 unauthenticated TLS. 687 In summary: this document does not apply to unauthenticated TLS use 688 cases. 690 6. IANA Considerations 692 This document requests no actions of IANA. [Note to RFC Editor: 693 please remove this whole section before publication.] 695 7. Security Considerations 697 This entire document discusses the security practices directly 698 affecting applications using the TLS protocol. This section contains 699 broader security considerations related to technologies used in 700 conjunction with or by TLS. 702 7.1. Host Name Validation 704 Application authors should take note that TLS implementations 705 frequently do not validate host names and must therefore determine if 706 the TLS implementation they are using does and, if not, write their 707 own validation code or consider changing the TLS implementation. 709 It is noted that the requirements regarding host name validation (and 710 in general, binding between the TLS layer and the protocol that runs 711 above it) vary between different protocols. For HTTPS, these 712 requirements are defined by Section 3 of [RFC2818]. 714 Readers are referred to [RFC6125] for further details regarding 715 generic host name validation in the TLS context. In addition, the 716 RFC contains a long list of example protocols, some of which 717 implement a policy very different from HTTPS. 719 If the host name is discovered indirectly and in an insecure manner 720 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD 721 NOT be used as a reference identifier [RFC6125] even when it matches 722 the presented certificate. This proviso does not apply if the host 723 name is discovered securely (for further discussion, see for example 724 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]). 726 Host name validation typically applies only to the leaf "end entity" 727 certificate. Naturally, in order to ensure proper authentication in 728 the context of the PKI, application clients need to verify the entire 729 certification path in accordance with [RFC5280] (see also [RFC6125]). 731 7.2. AES-GCM 733 Section 4.2 above recommends the use of the AES-GCM authenticated 734 encryption algorithm. Please refer to [RFC5246], Section 11 for 735 general security considerations when using TLS 1.2, and to [RFC5288], 736 Section 6 for security considerations that apply specifically to AES- 737 GCM when used with TLS. 739 7.3. Forward Secrecy 741 Forward secrecy (also often called Perfect Forward Secrecy or "PFS" 742 and defined in [RFC4949]) is a defense against an attacker who 743 records encrypted conversations where the session keys are only 744 encrypted with the communicating parties' long-term keys. Should the 745 attacker be able to obtain these long-term keys at some point later 746 in time, he will be able to decrypt the session keys and thus the 747 entire conversation. In the context of TLS and DTLS, such compromise 748 of long-term keys is not entirely implausible. It can happen, for 749 example, due to: 751 o A client or server being attacked by some other attack vector, and 752 the private key retrieved. 754 o A long-term key retrieved from a device that has been sold or 755 otherwise decommissioned without prior wiping. 757 o A long-term key used on a device as a default key [Heninger2012]. 759 o A key generated by a Trusted Third Party like a CA, and later 760 retrieved from it either by extortion or compromise 761 [Soghoian2011]. 763 o A cryptographic break-through, or the use of asymmetric keys with 764 insufficient length [Kleinjung2010]. 766 o Social engineering attacks against system administrators. 768 o Collection of private keys from inadequately protected backups. 770 Forward secrecy ensures in such cases that the session keys cannot be 771 determined even by an attacker who obtains the long-term keys some 772 time after the conversation. It also protects against an attacker 773 who is in possession of the long-term keys, but remains passive 774 during the conversation. 776 Forward secrecy is generally achieved by using the Diffie-Hellman 777 scheme to derive session keys. The Diffie-Hellman scheme has both 778 parties maintain private secrets and send parameters over the network 779 as modular powers over certain cyclic groups. The properties of the 780 so-called Discrete Logarithm Problem (DLP) allow the parties to 781 derive the session keys without an eavesdropper being able to do so. 782 There is currently no known attack against DLP if sufficiently large 783 parameters are chosen. A variant of the Diffie-Hellman scheme uses 784 Elliptic Curves instead of the originally proposed modular 785 arithmetics. 787 Unfortunately, many TLS/DTLS cipher suites were defined that do not 788 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This 789 document therefore advocates strict use of forward-secrecy-only 790 ciphers. 792 7.4. Diffie-Hellman Exponent Reuse 794 For performance reasons, many TLS implementations reuse Diffie- 795 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple 796 connections. Such reuse can result in major security issues: 798 o If exponents are reused for a long time (e.g., more than a few 799 hours), an attacker who gains access to the host can decrypt 800 previous connections. In other words, exponent reuse negates the 801 effects of forward secrecy. 803 o TLS implementations that reuse exponents should test the DH public 804 key they receive for group membership, in order to avoid some 805 known attacks. These tests are not standardized in TLS at the 806 time of writing. See [RFC6989] for recipient tests required of 807 IKEv2 implementations that reuse DH exponents. 809 7.5. Certificate Revocation 811 The following considerations and recommendations represent the 812 current state of the art regarding certificate revocation, even 813 though no complete and efficient solution exists for the problem of 814 checking the revocation status of common public key certificates 815 (a.k.a. PKIX certificates, [RFC5280]): 817 o Although Certificate Revocation Lists (CRLs) are the most widely 818 supported mechanism for distributing revocation information, they 819 have known scaling challenges that limit their usefulness (despite 820 workarounds such as partitioned CRLS and delta CRLs). 822 o Proprietary mechanisms that embed revocation lists in the Web 823 browser's configuration database cannot scale beyond a small 824 number of the most heavily used Web servers. 826 o The On-Line Certification Status Protocol (OCSP) [RFC6960] 827 presents both scaling and privacy issues. In addition, clients 828 typically "soft-fail", meaning that they do not abort the TLS 829 connection if the OCSP server does not respond (however, this 830 might be a workaround to avoid denial of service attacks if an 831 OSCP responder is taken offline). 833 o OCSP stapling (Section 8 of [RFC6066]) resolves the operational 834 issues with OCSP, but is still ineffective in the presence of a 835 MITM attacker because the attacker can simply ignore the client's 836 request for a stapled OCSP response. 838 o OCSP stapling as defined in [RFC6066] does not extend to 839 intermediate certificates used in a certificate chain. Although 840 [RFC6961] addresses this shortcoming, it is a recent addition 841 without much deployment. 843 o Both CRLs and OSCP depend on relatively reliable connectivity to 844 the Internet, which might not be available to certain kinds of 845 nodes (such as newly provisioned devices that need to establish a 846 secure connection in order to boot up for the first time). 848 With regard to PKIX certificates, servers SHOULD support the 849 following as a best practice given the current state of the art and 850 as a foundation for a possible future solution: 852 1. OCSP [RFC6960] 854 2. Both the status_request extension defined in [RFC6066] and the 855 status_request_v2 extension defined in [RFC6961] (this might 856 enable interoperability with the widest range of clients) 858 3. The OCSP stapling extension defined in [RFC6961] 860 The foregoing considerations do not apply to scenarios where the 861 DANE-TLSA resource record [RFC6698] is used to signal to a client 862 which certificate a server considers valid and good to use for TLS 863 connections. 865 8. Acknowledgments 867 Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen 868 Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson 869 Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, 870 Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom 871 Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean 872 Turner, and Aaron Zauner for their feedback and suggested 873 improvements. Thanks also to Brian Smith, who has provided a great 874 resource in his "Proposal to Change the Default TLS Ciphersuites 875 Offered by Browsers" [Smith2013]. Finally, thanks to all others who 876 commented on the TLS, UTA, and other discussion lists but who are not 877 mentioned here by name. 879 Robert Sparks and Dave Waltermire provided helpful reviews on behalf 880 of the General Area Review Team and the Security Directorate, 881 respectively. 883 The authors gratefully acknowledge the assistance of Leif Johansson 884 and Orit Levin as the working group chairs and Pete Resnick as the 885 sponsoring Area Director. 887 9. References 889 9.1. Normative References 891 [I-D.ietf-tls-prohibiting-rc4] 892 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 893 tls-prohibiting-rc4-01 (work in progress), October 2014. 895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 896 Requirement Levels", BCP 14, RFC 2119, March 1997. 898 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 900 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 901 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 902 RFC 3766, April 2004. 904 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 905 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 906 for Transport Layer Security (TLS)", RFC 4492, May 2006. 908 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 909 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 911 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 912 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 913 August 2008. 915 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with 916 SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 917 August 2008. 919 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 920 "Transport Layer Security (TLS) Renegotiation Indication 921 Extension", RFC 5746, February 2010. 923 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 924 Verification of Domain-Based Application Service Identity 925 within Internet Public Key Infrastructure Using X.509 926 (PKIX) Certificates in the Context of Transport Layer 927 Security (TLS)", RFC 6125, March 2011. 929 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 930 (SSL) Version 2.0", RFC 6176, March 2011. 932 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 933 Security Version 1.2", RFC 6347, January 2012. 935 9.2. Informative References 937 [CAB-Baseline] 938 CA/Browser Forum, , "Baseline Requirements for the 939 Issuance and Management of Publicly-Trusted Certificates 940 Version 1.1.6", 2013, . 943 [DegabrieleP07] 944 Degabriele, J. and K. Paterson, "Attacking the IPsec 945 standards in encryption-only configurations", 2007, 946 . 948 [ECRYPT-II] 949 Smart, N., "ECRYPT II Yearly Report on Algorithms and 950 Keysizes (2011-2012)", 2012, 951 . 953 [Heninger2012] 954 Heninger, N., Durumeric, Z., Wustrow, E., and J. 955 Halderman, "Mining Your Ps and Qs: Detection of Widespread 956 Weak Keys in Network Devices", Usenix Security Symposium 957 2012, 2012. 959 [I-D.ietf-dane-smtp-with-dane] 960 Dukhovni, V. and W. Hardaker, "SMTP security via 961 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 962 (work in progress), May 2014. 964 [I-D.ietf-dane-srv] 965 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 966 Based Authentication of Named Entities (DANE) TLSA Records 967 with SRV Records", draft-ietf-dane-srv-06 (work in 968 progress), June 2014. 970 [I-D.ietf-tls-downgrade-scsv] 971 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 972 Suite Value (SCSV) for Preventing Protocol Downgrade 973 Attacks", draft-ietf-tls-downgrade-scsv-02 (work in 974 progress), November 2014. 976 [Kleinjung2010] 977 Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", 978 CRYPTO 10, 2010, . 980 [Krawczyk2001] 981 Krawczyk, H., "The order of encryption and authentication 982 for protecting communications (Or: how secure is SSL?)", 983 CRYPTO 01, 2001, . 985 [Multiple-Encryption] 986 Merkle, R. and M. Hellman, "On the security of multiple 987 encryption", Communications of the ACM 24, 1981, 988 . 990 [NIST.SP.800-56A] 991 Barker, E., Chen, L., Roginsky, A., and M. Smid, 992 "Recommendation for Pair-Wise Key Establishment Schemes 993 Using Discrete Logarithm Cryptography", NIST Special 994 Publication 800-56A, 2013, . 997 [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE 998 Bites: Exploiting the SSL 3.0 Fallback", 2014, . 1001 [PatersonRS11] 1002 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size 1003 does matter: attacks and proofs for the TLS record 1004 protocol", 2011, 1005 . 1007 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1008 RFC 2246, January 1999. 1010 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1011 Algorithm and Its Use with IPsec", RFC 3602, September 1012 2003. 1014 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1015 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1017 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1018 Security", RFC 4347, April 2006. 1020 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1021 4949, August 2007. 1023 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1024 "Transport Layer Security (TLS) Session Resumption without 1025 Server-Side State", RFC 5077, January 2008. 1027 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1028 Encryption", RFC 5116, January 2008. 1030 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1031 Housley, R., and W. Polk, "Internet X.509 Public Key 1032 Infrastructure Certificate and Certificate Revocation List 1033 (CRL) Profile", RFC 5280, May 2008. 1035 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1036 Extension Definitions", RFC 6066, January 2011. 1038 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1039 Curve Cryptography Algorithms", RFC 6090, February 2011. 1041 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1042 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1043 August 2011. 1045 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1046 Layer Security (TLS)", RFC 6460, January 2012. 1048 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1049 of Named Entities (DANE) Transport Layer Security (TLS) 1050 Protocol: TLSA", RFC 6698, August 2012. 1052 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1053 Transport Security (HSTS)", RFC 6797, November 2012. 1055 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1056 Galperin, S., and C. Adams, "X.509 Internet Public Key 1057 Infrastructure Online Certificate Status Protocol - OCSP", 1058 RFC 6960, June 2013. 1060 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1061 Multiple Certificate Status Request Extension", RFC 6961, 1062 June 2013. 1064 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 1065 Tests for the Internet Key Exchange Protocol Version 2 1066 (IKEv2)", RFC 6989, July 2013. 1068 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1069 Most of the Time", RFC 7435, December 2014. 1071 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1072 Known Attacks on Transport Layer Security (TLS) and 1073 Datagram TLS (DTLS)", RFC 7457, February 2015. 1075 [Smith2013] 1076 Smith, B., "Proposal to Change the Default TLS 1077 Ciphersuites Offered by Browsers.", 2013, . 1080 [Soghoian2011] 1081 Soghoian, C. and S. Stamm, "Certified lies: Detecting and 1082 defeating government interception attacks against SSL.", 1083 Proc. 15th Int. Conf. Financial Cryptography and Data 1084 Security , 2011. 1086 [triple-handshake] 1087 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 1088 "Triple Handshakes Considered Harmful: Breaking and Fixing 1089 Authentication over TLS", 2014, . 1092 Appendix A. Change Log 1094 Note to RFC Editor: please remove this section before publication. 1096 A.1. draft-ietf-uta-tls-bcp-08 1098 o More WGLC feedback. 1100 o TLS 1.1 is now SHOULD NOT, just like TLS 1.0. 1102 o SHOULD NOT use curves of less than 192 bits for ECDH. 1104 o Clarification regarding OCSP and OSCP stapling. 1106 A.2. draft-ietf-uta-tls-bcp-07 1108 o WGLC feedback. 1110 A.3. draft-ietf-uta-tls-bcp-06 1112 o Undo unauthenticated TLS, following another long thread on the 1113 list. 1115 A.4. draft-ietf-uta-tls-bcp-05 1117 o Lots of comments by Sean Turner. 1119 o Unauthenticated TLS, following a long thread on the list. 1121 A.5. draft-ietf-uta-tls-bcp-04 1123 o Some cleanup, and input from TLS WG discussion on applicability. 1125 A.6. draft-ietf-uta-tls-bcp-03 1127 o Disallow truncated HMAC. 1129 o Applicability to DTLS. 1131 o Some more text restructuring. 1133 o Host name validation is sometimes irrelevant. 1135 o HSTS: MUST implement, SHOULD deploy. 1137 o Session identities are not protected, only tickets are. 1139 o Clarified the target audience. 1141 A.7. draft-ietf-uta-tls-bcp-02 1143 o Rearranged some sections for clarity and re-styled the text so 1144 that normative text is followed by rationale where possible. 1146 o Removed the recommendation to use Brainpool curves. 1148 o Triple Handshake mitigation. 1150 o MUST NOT negotiate algorithms lower than 112 bits of security. 1152 o MUST implement SNI, but use per local policy. 1154 o Changed SHOULD NOT negotiate or fall back to SSLv3 to MUST NOT. 1156 o Added hostname validation. 1158 o Non-normative discussion of DH exponent reuse. 1160 A.8. draft-ietf-tls-bcp-01 1162 o Clarified that specific TLS-using protocols may have stricter 1163 requirements. 1165 o Changed TLS 1.0 from MAY to SHOULD NOT. 1167 o Added discussion of "optional TLS" and HSTS. 1169 o Recommended use of the Signature Algorithm and Renegotiation Info 1170 extensions. 1172 o Use of a strong cipher for a resumption ticket: changed SHOULD to 1173 MUST. 1175 o Added an informational discussion of certificate revocation, but 1176 no recommendations. 1178 A.9. draft-ietf-tls-bcp-00 1180 o Initial WG version, with only updated references. 1182 A.10. draft-sheffer-tls-bcp-02 1184 o Reorganized the content to focus on recommendations. 1186 o Moved description of attacks to a separate document (draft- 1187 sheffer-uta-tls-attacks). 1189 o Strengthened recommendations regarding session resumption. 1191 A.11. draft-sheffer-tls-bcp-01 1193 o Clarified our motivation in the introduction. 1195 o Added a section justifying the need for forward secrecy. 1197 o Added recommendations for RSA and DH parameter lengths. Moved 1198 from DHE to ECDHE, with a discussion on whether/when DHE is 1199 appropriate. 1201 o Recommendation to avoid fallback to SSLv3. 1203 o Initial information about browser support - more still needed! 1205 o More clarity on compression. 1207 o Client can offer stronger cipher suites. 1209 o Discussion of the regular TLS mandatory cipher suite. 1211 A.12. draft-sheffer-tls-bcp-00 1213 o Initial version. 1215 Authors' Addresses 1217 Yaron Sheffer 1218 Porticor 1219 29 HaHarash St. 1220 Hod HaSharon 4501303 1221 Israel 1223 Email: yaronf.ietf@gmail.com 1225 Ralph Holz 1226 Technische Universitaet Muenchen 1227 Boltzmannstr. 3 1228 Garching 85748 1229 Germany 1231 Email: ralph.ietf@gmail.com 1232 Peter Saint-Andre 1233 &yet 1235 Email: peter@andyet.com 1236 URI: https://andyet.com/