7Internet Engineering Task Force (IETF) Y. Sheffer
8Request for Comments: 7525 Intuit
10Category: Best Current Practice NICTA
11ISSN: 2070-1721 P. Saint-Andre
16 Recommendations for Secure Use of Transport Layer Security (TLS)
17 and Datagram Transport Layer Security (DTLS)
21 Transport Layer Security (TLS) and Datagram Transport Layer Security
22 (DTLS) are widely used to protect data exchanged over application
23 protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
24 last few years, several serious attacks on TLS have emerged,
25 including attacks on its most commonly used cipher suites and their
26 modes of operation. This document provides recommendations for
27 improving the security of deployed services that use TLS and DTLS.
28 The recommendations are applicable to the majority of use cases.
32 This memo documents an Internet Best Current Practice.
34 This document is a product of the Internet Engineering Task Force
35 (IETF). It represents the consensus of the IETF community. It has
36 received public review and has been approved for publication by the
37 Internet Engineering Steering Group (IESG). Further information on
38 BCPs is available in Section 2 of RFC 5741.
40 Information about the current status of this document, any errata,
41 and how to provide feedback on it may be obtained at
42 http://www.rfc-editor.org/info/rfc7525.
58Sheffer, et al. Best Current Practice [Page 1]
60RFC 7525 TLS Recommendations May 2015
65 Copyright (c) 2015 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
114Sheffer, et al. Best Current Practice [Page 2]
116RFC 7525 TLS Recommendations May 2015
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
122 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
123 3. General Recommendations . . . . . . . . . . . . . . . . . . . 5
124 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5
125 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5
126 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6
127 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7
128 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7
129 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
130 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8
131 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
132 3.6. Server Name Indication . . . . . . . . . . . . . . . . . 9
133 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 9
134 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 9
135 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 11
136 4.2.1. Implementation Details . . . . . . . . . . . . . . . 12
137 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 12
138 4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites . 13
139 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 14
140 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 15
141 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 15
142 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 16
143 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
144 6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 17
145 6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 18
146 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 18
147 6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 19
148 6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 19
149 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
150 7.1. Normative References . . . . . . . . . . . . . . . . . . 21
151 7.2. Informative References . . . . . . . . . . . . . . . . . 22
152 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
170Sheffer, et al. Best Current Practice [Page 3]
172RFC 7525 TLS Recommendations May 2015
177 Transport Layer Security (TLS) [RFC5246] and Datagram Transport
178 Security Layer (DTLS) [RFC6347] are widely used to protect data
179 exchanged over application protocols such as HTTP, SMTP, IMAP, POP,
180 SIP, and XMPP. Over the last few years, several serious attacks on
181 TLS have emerged, including attacks on its most commonly used cipher
182 suites and their modes of operation. For instance, both the AES-CBC
183 [RFC3602] and RC4 [RFC7465] encryption algorithms, which together
184 have been the most widely deployed ciphers, have been attacked in the
185 context of TLS. A companion document [RFC7457] provides detailed
186 information about these attacks and will help the reader understand
187 the rationale behind the recommendations provided here.
189 Because of these attacks, those who implement and deploy TLS and DTLS
190 need updated guidance on how TLS can be used securely. This document
191 provides guidance for deployed services as well as for software
192 implementations, assuming the implementer expects his or her code to
193 be deployed in environments defined in Section 5. In fact, this
194 document calls for the deployment of algorithms that are widely
195 implemented but not yet widely deployed. Concerning deployment, this
196 document targets a wide audience -- namely, all deployers who wish to
197 add authentication (be it one-way only or mutual), confidentiality,
198 and data integrity protection to their communications.
200 The recommendations herein take into consideration the security of
201 various mechanisms, their technical maturity and interoperability,
202 and their prevalence in implementations at the time of writing.
203 Unless it is explicitly called out that a recommendation applies to
204 TLS alone or to DTLS alone, each recommendation applies to both TLS
207 It is expected that the TLS 1.3 specification will resolve many of
208 the vulnerabilities listed in this document. A system that deploys
209 TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below.
210 This document is likely to be updated after TLS 1.3 gets noticeable
213 These are minimum recommendations for the use of TLS in the vast
214 majority of implementation and deployment scenarios, with the
215 exception of unauthenticated TLS (see Section 5). Other
216 specifications that reference this document can have stricter
217 requirements related to one or more aspects of the protocol, based on
218 their particular circumstances (e.g., for use with a particular
219 application protocol); when that is the case, implementers are
220 advised to adhere to those stricter requirements. Furthermore, this
226Sheffer, et al. Best Current Practice [Page 4]
228RFC 7525 TLS Recommendations May 2015
231 document provides a floor, not a ceiling, so stronger options are
232 always allowed (e.g., depending on differing evaluations of the
233 importance of cryptographic strength vs. computational load).
235 Community knowledge about the strength of various algorithms and
236 feasible attacks can change quickly, and experience shows that a Best
237 Current Practice (BCP) document about security is a point-in-time
238 statement. Readers are advised to seek out any errata or updates
239 that apply to this document.
243 A number of security-related terms in this document are used in the
244 sense defined in [RFC4949].
246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
248 document are to be interpreted as described in [RFC2119].
2503. General Recommendations
252 This section provides general recommendations on the secure use of
253 TLS. Recommendations related to cipher suites are discussed in the
2563.1. Protocol Versions
2583.1.1. SSL/TLS Protocol Versions
260 It is important both to stop using old, less secure versions of SSL/
261 TLS and to start using modern, more secure versions; therefore, the
262 following are the recommendations concerning TLS/SSL protocol
265 o Implementations MUST NOT negotiate SSL version 2.
267 Rationale: Today, SSLv2 is considered insecure [RFC6176].
269 o Implementations MUST NOT negotiate SSL version 3.
271 Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and
272 plugged some significant security holes but did not support strong
273 cipher suites. SSLv3 does not support TLS extensions, some of
274 which (e.g., renegotiation_info [RFC5746]) are security-critical.
275 In addition, with the emergence of the POODLE attack [POODLE],
276 SSLv3 is now widely recognized as fundamentally insecure. See
277 [DEP-SSLv3] for further details.
282Sheffer, et al. Best Current Practice [Page 5]
284RFC 7525 TLS Recommendations May 2015
287 o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246];
288 the only exception is when no higher version is available in the
291 Rationale: TLS 1.0 (published in 1999) does not support many
292 modern, strong cipher suites. In addition, TLS 1.0 lacks a per-
293 record Initialization Vector (IV) for CBC-based cipher suites and
294 does not warn against common padding errors.
296 o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346];
297 the only exception is when no higher version is available in the
300 Rationale: TLS 1.1 (published in 2006) is a security improvement
301 over TLS 1.0 but still does not support certain stronger cipher
304 o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
305 negotiate TLS version 1.2 over earlier versions of TLS.
307 Rationale: Several stronger cipher suites are available only with
308 TLS 1.2 (published in 2008). In fact, the cipher suites
309 recommended by this document (Section 4.2 below) are only
310 available in TLS 1.2.
312 This BCP applies to TLS 1.2 and also to earlier versions. It is not
313 safe for readers to assume that the recommendations in this BCP apply
314 to any future version of TLS.
3163.1.2. DTLS Protocol Versions
318 DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS
319 1.1 was published. The following are the recommendations with
322 o Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347].
324 Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
326 o Implementations MUST support and MUST prefer to negotiate DTLS
327 version 1.2 [RFC6347].
329 Version 1.2 of DTLS correlates to version 1.2 of TLS (see above).
330 (There is no version 1.1 of DTLS.)
338Sheffer, et al. Best Current Practice [Page 6]
340RFC 7525 TLS Recommendations May 2015
3433.1.3. Fallback to Lower Versions
345 Clients that "fall back" to lower versions of the protocol after the
346 server rejects higher versions of the protocol MUST NOT fall back to
349 Rationale: Some client implementations revert to lower versions of
350 TLS or even to SSLv3 if the server rejected higher versions of the
351 protocol. This fallback can be forced by a man-in-the-middle (MITM)
352 attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS
353 1.2, the version recommended by this document. While TLS 1.0-only
354 servers are still quite common, IP scans show that SSLv3-only servers
355 amount to only about 3% of the current Web server population. (At
356 the time of this writing, an explicit method for preventing downgrade
357 attacks has been defined recently in [RFC7507].)
361 The following recommendations are provided to help prevent SSL
362 Stripping (an attack that is summarized in Section 2.1 of [RFC7457]):
364 o In cases where an application protocol allows implementations or
365 deployments a choice between strict TLS configuration and dynamic
366 upgrade from unencrypted to TLS-protected traffic (such as
367 STARTTLS), clients and servers SHOULD prefer strict TLS
370 o Application protocols typically provide a way for the server to
371 offer TLS during an initial protocol exchange, and sometimes also
372 provide a way for the server to advertise support for TLS (e.g.,
373 through a flag indicating that TLS is required); unfortunately,
374 these indications are sent before the communication channel is
375 encrypted. A client SHOULD attempt to negotiate TLS even if these
376 indications are not communicated by the server.
378 o HTTP client and server implementations MUST support the HTTP
379 Strict Transport Security (HSTS) header [RFC6797], in order to
380 allow Web servers to advertise that they are willing to accept
383 o Web servers SHOULD use HSTS to indicate that they are willing to
384 accept TLS-only clients, unless they are deployed in such a way
385 that using HSTS would in fact weaken overall security (e.g., it
386 can be problematic to use HSTS with self-signed certificates, as
387 described in Section 11.3 of [RFC6797]).
394Sheffer, et al. Best Current Practice [Page 7]
396RFC 7525 TLS Recommendations May 2015
399 Rationale: Combining unprotected and TLS-protected communication
400 opens the way to SSL Stripping and similar attacks, since an initial
401 part of the communication is not integrity protected and therefore
402 can be manipulated by an attacker whose goal is to keep the
403 communication in the clear.
407 In order to help prevent compression-related attacks (summarized in
408 Section 2.6 of [RFC7457]), implementations and deployments SHOULD
409 disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless
410 the application protocol in question has been shown not to be open to
413 Rationale: TLS compression has been subject to security attacks, such
416 Implementers should note that compression at higher protocol levels
417 can allow an active attacker to extract cleartext information from
418 the connection. The BREACH attack is one such case. These issues
419 can only be mitigated outside of TLS and are thus outside the scope
420 of this document. See Section 2.6 of [RFC7457] for further details.
4223.4. TLS Session Resumption
424 If TLS session resumption is used, care ought to be taken to do so
425 safely. In particular, when using session tickets [RFC5077], the
426 resumption information MUST be authenticated and encrypted to prevent
427 modification or eavesdropping by an attacker. Further
428 recommendations apply to session tickets:
430 o A strong cipher suite MUST be used when encrypting the ticket (as
431 least as strong as the main TLS cipher suite).
433 o Ticket keys MUST be changed regularly, e.g., once every week, so
434 as not to negate the benefits of forward secrecy (see Section 6.3
435 for details on forward secrecy).
437 o For similar reasons, session ticket validity SHOULD be limited to
438 a reasonable duration (e.g., half as long as ticket key validity).
440 Rationale: session resumption is another kind of TLS handshake, and
441 therefore must be as secure as the initial handshake. This document
442 (Section 4) recommends the use of cipher suites that provide forward
443 secrecy, i.e. that prevent an attacker who gains momentary access to
444 the TLS endpoint (either client or server) and its secrets from
445 reading either past or future communication. The tickets must be
446 managed so as not to negate this security property.
450Sheffer, et al. Best Current Practice [Page 8]
452RFC 7525 TLS Recommendations May 2015
4553.5. TLS Renegotiation
457 Where handshake renegotiation is implemented, both clients and
458 servers MUST implement the renegotiation_info extension, as defined
461 The most secure option for countering the Triple Handshake attack is
462 to refuse any change of certificates during renegotiation. In
463 addition, TLS clients SHOULD apply the same validation policy for all
464 certificates received over a connection. The [triple-handshake]
465 document suggests several other possible countermeasures, such as
466 binding the master secret to the full handshake (see [SESSION-HASH])
467 and binding the abbreviated session resumption handshake to the
468 original full handshake. Although the latter two techniques are
469 still under development and thus do not qualify as current practices,
470 those who implement and deploy TLS are advised to watch for further
471 development of appropriate countermeasures.
4733.6. Server Name Indication
475 TLS implementations MUST support the Server Name Indication (SNI)
476 extension defined in Section 3 of [RFC6066] for those higher-level
477 protocols that would benefit from it, including HTTPS. However, the
478 actual use of SNI in particular circumstances is a matter of local
481 Rationale: SNI supports deployment of multiple TLS-protected virtual
482 servers on a single address, and therefore enables fine-grained
483 security for these virtual servers, by allowing each one to have its
4864. Recommendations: Cipher Suites
488 TLS and its implementations provide considerable flexibility in the
489 selection of cipher suites. Unfortunately, some available cipher
490 suites are insecure, some do not provide the targeted security
491 services, and some no longer provide enough security. Incorrectly
492 configuring a server leads to no or reduced security. This section
493 includes recommendations on the selection and negotiation of cipher
4964.1. General Guidelines
498 Cryptographic algorithms weaken over time as cryptanalysis improves:
499 algorithms that were once considered strong become weak. Such
500 algorithms need to be phased out over time and replaced with more
501 secure cipher suites. This helps to ensure that the desired security
502 properties still hold. SSL/TLS has been in existence for almost 20
506Sheffer, et al. Best Current Practice [Page 9]
508RFC 7525 TLS Recommendations May 2015
511 years and many of the cipher suites that have been recommended in
512 various versions of SSL/TLS are now considered weak or at least not
513 as strong as desired. Therefore, this section modernizes the
514 recommendations concerning cipher suite selection.
516 o Implementations MUST NOT negotiate the cipher suites with NULL
519 Rationale: The NULL cipher suites do not encrypt traffic and so
520 provide no confidentiality services. Any entity in the network
521 with access to the connection can view the plaintext of contents
522 being exchanged by the client and server. (Nevertheless, this
523 document does not discourage software from implementing NULL
524 cipher suites, since they can be useful for testing and
527 o Implementations MUST NOT negotiate RC4 cipher suites.
529 Rationale: The RC4 stream cipher has a variety of cryptographic
530 weaknesses, as documented in [RFC7465]. Note that DTLS
531 specifically forbids the use of RC4 already.
533 o Implementations MUST NOT negotiate cipher suites offering less
534 than 112 bits of security, including so-called "export-level"
535 encryption (which provide 40 or 56 bits of security).
537 Rationale: Based on [RFC3766], at least 112 bits of security is
538 needed. 40-bit and 56-bit security are considered insecure today.
539 TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers.
541 o Implementations SHOULD NOT negotiate cipher suites that use
542 algorithms offering less than 128 bits of security.
544 Rationale: Cipher suites that offer between 112-bits and 128-bits
545 of security are not considered weak at this time; however, it is
546 expected that their useful lifespan is short enough to justify
547 supporting stronger cipher suites at this time. 128-bit ciphers
548 are expected to remain secure for at least several years, and
549 256-bit ciphers until the next fundamental technology
550 breakthrough. Note that, because of so-called "meet-in-the-
551 middle" attacks [Multiple-Encryption], some legacy cipher suites
552 (e.g., 168-bit 3DES) have an effective key length that is smaller
553 than their nominal key length (112 bits in the case of 3DES).
554 Such cipher suites should be evaluated according to their
555 effective key length.
562Sheffer, et al. Best Current Practice [Page 10]
564RFC 7525 TLS Recommendations May 2015
567 o Implementations SHOULD NOT negotiate cipher suites based on RSA
568 key transport, a.k.a. "static RSA".
570 Rationale: These cipher suites, which have assigned values
571 starting with the string "TLS_RSA_WITH_*", have several drawbacks,
572 especially the fact that they do not support forward secrecy.
574 o Implementations MUST support and prefer to negotiate cipher suites
575 offering forward secrecy, such as those in the Ephemeral Diffie-
576 Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and
579 Rationale: Forward secrecy (sometimes called "perfect forward
580 secrecy") prevents the recovery of information that was encrypted
581 with older session keys, thus limiting the amount of time during
582 which attacks can be successful. See Section 6.3 for a detailed
5854.2. Recommended Cipher Suites
587 Given the foregoing considerations, implementation and deployment of
588 the following cipher suites is RECOMMENDED:
590 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
592 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
594 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
596 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
598 These cipher suites are supported only in TLS 1.2 because they are
599 authenticated encryption (AEAD) algorithms [RFC5116].
601 Typically, in order to prefer these suites, the order of suites needs
602 to be explicitly configured in server software. (See [BETTERCRYPTO]
603 for helpful deployment guidelines, but note that its recommendations
604 differ from the current document in some details.) It would be ideal
605 if server software implementations were to prefer these suites by
608 Some devices have hardware support for AES-CCM but not AES-GCM, so
609 they are unable to follow the foregoing recommendations regarding
610 cipher suites. There are even devices that do not support public key
611 cryptography at all, but they are out of scope entirely.
618Sheffer, et al. Best Current Practice [Page 11]
620RFC 7525 TLS Recommendations May 2015
6234.2.1. Implementation Details
625 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the
626 first proposal to any server, unless they have prior knowledge that
627 the server cannot respond to a TLS 1.2 client_hello message.
629 Servers MUST prefer this cipher suite over weaker cipher suites
630 whenever it is proposed, even if it is not the first proposal.
632 Clients are of course free to offer stronger cipher suites, e.g.,
633 using AES-256; when they do, the server SHOULD prefer the stronger
634 cipher suite unless there are compelling reasons (e.g., seriously
635 degraded performance) to choose otherwise.
637 This document does not change the mandatory-to-implement TLS cipher
638 suite(s) prescribed by TLS. To maximize interoperability, RFC 5246
639 mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher
640 suite, which is significantly weaker than the cipher suites
641 recommended here. (The GCM mode does not suffer from the same
642 weakness, caused by the order of MAC-then-Encrypt in TLS
643 [Krawczyk2001], since it uses an AEAD mode of operation.)
644 Implementers should consider the interoperability gain against the
645 loss in security when deploying the TLS_RSA_WITH_AES_128_CBC_SHA
646 cipher suite. Other application protocols specify other cipher
647 suites as mandatory to implement (MTI).
649 Note that some profiles of TLS 1.2 use different cipher suites. For
650 example, [RFC6460] defines a profile that uses the
651 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
652 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.
654 [RFC4492] allows clients and servers to negotiate ECDH parameters
655 (curves). Both clients and servers SHOULD include the "Supported
656 Elliptic Curves" extension [RFC4492]. For interoperability, clients
657 and servers SHOULD support the NIST P-256 (secp256r1) curve
658 [RFC4492]. In addition, clients SHOULD send an ec_point_formats
659 extension with a single element, "uncompressed".
6614.3. Public Key Length
663 When using the cipher suites recommended in this document, two public
664 keys are normally used in the TLS handshake: one for the Diffie-
665 Hellman key agreement and one for server authentication. Where a
666 client certificate is used, a third public key is added.
668 With a key exchange based on modular exponential (MODP) Diffie-
669 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048
670 bits are RECOMMENDED.
674Sheffer, et al. Best Current Practice [Page 12]
676RFC 7525 TLS Recommendations May 2015
679 Rationale: For various reasons, in practice, DH keys are typically
680 generated in lengths that are powers of two (e.g., 2^10 = 1024 bits,
681 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits
682 would be roughly equivalent to only an 80-bit symmetric key
683 [RFC3766], it is better to use keys longer than that for the "DHE"
684 family of cipher suites. A DH key of 1926 bits would be roughly
685 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048
686 bits might be sufficient for at least the next 10 years
687 [NIST.SP.800-56A]. See Section 4.4 for additional information on the
688 use of MODP Diffie-Hellman in TLS.
690 As noted in [RFC3766], correcting for the emergence of a TWIRL
691 machine would imply that 1024-bit DH keys yield about 65 bits of
692 equivalent strength and that a 2048-bit DH key would yield about 92
693 bits of equivalent strength.
695 With regard to ECDH keys, the IANA "EC Named Curve Registry" (within
696 the "Transport Layer Security (TLS) Parameters" registry [IANA-TLS])
697 contains 160-bit elliptic curves that are considered to be roughly
698 equivalent to only an 80-bit symmetric key [ECRYPT-II]. Curves of
699 less than 192 bits SHOULD NOT be used.
701 When using RSA, servers SHOULD authenticate using certificates with
702 at least a 2048-bit modulus for the public key. In addition, the use
703 of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for
704 more details). Clients SHOULD indicate to servers that they request
705 SHA-256, by using the "Signature Algorithms" extension defined in
7084.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites
710 Not all TLS implementations support both modular exponential (MODP)
711 and elliptic curve (EC) Diffie-Hellman groups, as required by
712 Section 4.2. Some implementations are severely limited in the length
713 of DH values. When such implementations need to be accommodated, the
714 following are RECOMMENDED (in priority order):
716 1. Elliptic Curve DHE with appropriately negotiated parameters
717 (e.g., the curve to be used) and a Message Authentication Code
718 (MAC) algorithm stronger than HMAC-SHA1 [RFC5289]
720 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit
721 Diffie-Hellman parameters
723 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters
730Sheffer, et al. Best Current Practice [Page 13]
732RFC 7525 TLS Recommendations May 2015
735 Rationale: Although Elliptic Curve Cryptography is widely deployed,
736 there are some communities where its adoption has been limited for
737 several reasons, including its complexity compared to modular
738 arithmetic and longstanding perceptions of IPR concerns (which, for
739 the most part, have now been resolved [RFC6090]). Note that ECDHE
740 cipher suites exist for both RSA and ECDSA certificates, so moving to
741 ECDHE cipher suites does not require moving away from RSA-based
742 certificates. On the other hand, there are two related issues
743 hindering effective use of MODP Diffie-Hellman cipher suites in TLS:
745 o There are no standardized, widely implemented protocol mechanisms
746 to negotiate the DH groups or parameter lengths supported by
749 o Many servers choose DH parameters of 1024 bits or fewer.
751 o There are widely deployed client implementations that reject
752 received DH parameters if they are longer than 1024 bits. In
753 addition, several implementations do not perform appropriate
754 validation of group parameters and are vulnerable to attacks
755 referenced in Section 2.9 of [RFC7457].
757 Note that with DHE and ECDHE cipher suites, the TLS master key only
758 depends on the Diffie-Hellman parameters and not on the strength of
759 the RSA certificate; moreover, 1024 bit MODP DH parameters are
760 generally considered insufficient at this time.
762 With MODP ephemeral DH, deployers ought to carefully evaluate
763 interoperability vs. security considerations when configuring their
768 Implementations MUST NOT use the Truncated HMAC extension, defined in
769 Section 7 of [RFC6066].
771 Rationale: the extension does not apply to the AEAD cipher suites
772 recommended above. However it does apply to most other TLS cipher
773 suites. Its use has been shown to be insecure in [PatersonRS11].
786Sheffer, et al. Best Current Practice [Page 14]
788RFC 7525 TLS Recommendations May 2015
7915. Applicability Statement
793 The recommendations of this document primarily apply to the
794 implementation and deployment of application protocols that are most
795 commonly used with TLS and DTLS on the Internet today. Examples
796 include, but are not limited to:
798 o Web software and services that wish to protect HTTP traffic with
801 o Email software and services that wish to protect IMAP, POP3, or
802 SMTP traffic with TLS.
804 o Instant-messaging software and services that wish to protect
805 Extensible Messaging and Presence Protocol (XMPP) or Internet
806 Relay Chat (IRC) traffic with TLS.
808 o Realtime media software and services that wish to protect Secure
809 Realtime Transport Protocol (SRTP) traffic with DTLS.
811 This document does not modify the implementation and deployment
812 recommendations (e.g., mandatory-to-implement cipher suites)
813 prescribed by existing application protocols that employ TLS or DTLS.
814 If the community that uses such an application protocol wishes to
815 modernize its usage of TLS or DTLS to be consistent with the best
816 practices recommended here, it needs to explicitly update the
817 existing application protocol definition (one example is [TLS-XMPP],
818 which updates [RFC6120]).
820 Designers of new application protocols developed through the Internet
821 Standards Process [RFC2026] are expected at minimum to conform to the
822 best practices recommended here, unless they provide documentation of
823 compelling reasons that would prevent such conformance (e.g.,
824 widespread deployment on constrained devices that lack support for
825 the necessary algorithms).
8275.1. Security Services
829 This document provides recommendations for an audience that wishes to
830 secure their communication with TLS to achieve the following:
832 o Confidentiality: all application-layer communication is encrypted
833 with the goal that no party should be able to decrypt it except
834 the intended receiver.
836 o Data integrity: any changes made to the communication in transit
837 are detectable by the receiver.
842Sheffer, et al. Best Current Practice [Page 15]
844RFC 7525 TLS Recommendations May 2015
847 o Authentication: an endpoint of the TLS communication is
848 authenticated as the intended entity to communicate with.
850 With regard to authentication, TLS enables authentication of one or
851 both endpoints in the communication. In the context of opportunistic
852 security [RFC7435], TLS is sometimes used without authentication. As
853 discussed in Section 5.2, considerations for opportunistic security
854 are not in scope for this document.
856 If deployers deviate from the recommendations given in this document,
857 they need to be aware that they might lose access to one of the
858 foregoing security services.
860 This document applies only to environments where confidentiality is
861 required. It recommends algorithms and configuration options that
862 enforce secrecy of the data in transit.
864 This document also assumes that data integrity protection is always
865 one of the goals of a deployment. In cases where integrity is not
866 required, it does not make sense to employ TLS in the first place.
867 There are attacks against confidentiality-only protection that
868 utilize the lack of integrity to also break confidentiality (see, for
869 instance, [DegabrieleP07] in the context of IPsec).
871 This document addresses itself to application protocols that are most
872 commonly used on the Internet with TLS and DTLS. Typically, all
873 communication between TLS clients and TLS servers requires all three
874 of the above security services. This is particularly true where TLS
875 clients are user agents like Web browsers or email software.
877 This document does not address the rarer deployment scenarios where
878 one of the above three properties is not desired, such as the use
879 case described in Section 5.2 below. As another scenario where
880 confidentiality is not needed, consider a monitored network where the
881 authorities in charge of the respective traffic domain require full
882 access to unencrypted (plaintext) traffic, and where users
883 collaborate and send their traffic in the clear.
8855.2. Opportunistic Security
887 There are several important scenarios in which the use of TLS is
888 optional, i.e., the client decides dynamically ("opportunistically")
889 whether to use TLS with a particular server or to connect in the
890 clear. This practice, often called "opportunistic security", is
891 described at length in [RFC7435] and is often motivated by a desire
892 for backward compatibility with legacy deployments.
898Sheffer, et al. Best Current Practice [Page 16]
900RFC 7525 TLS Recommendations May 2015
903 In these scenarios, some of the recommendations in this document
904 might be too strict, since adhering to them could cause fallback to
905 cleartext, a worse outcome than using TLS with an outdated protocol
906 version or cipher suite.
908 This document specifies best practices for TLS in general. A
909 separate document containing recommendations for the use of TLS with
910 opportunistic security is to be completed in the future.
9126. Security Considerations
914 This entire document discusses the security practices directly
915 affecting applications using the TLS protocol. This section contains
916 broader security considerations related to technologies used in
917 conjunction with or by TLS.
9196.1. Host Name Validation
921 Application authors should take note that some TLS implementations do
922 not validate host names. If the TLS implementation they are using
923 does not validate host names, authors might need to write their own
924 validation code or consider using a different TLS implementation.
926 It is noted that the requirements regarding host name validation
927 (and, in general, binding between the TLS layer and the protocol that
928 runs above it) vary between different protocols. For HTTPS, these
929 requirements are defined by Section 3 of [RFC2818].
931 Readers are referred to [RFC6125] for further details regarding
932 generic host name validation in the TLS context. In addition, that
933 RFC contains a long list of example protocols, some of which
934 implement a policy very different from HTTPS.
936 If the host name is discovered indirectly and in an insecure manner
937 (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD
938 NOT be used as a reference identifier [RFC6125] even when it matches
939 the presented certificate. This proviso does not apply if the host
940 name is discovered securely (for further discussion, see [DANE-SRV]
943 Host name validation typically applies only to the leaf "end entity"
944 certificate. Naturally, in order to ensure proper authentication in
945 the context of the PKI, application clients need to verify the entire
946 certification path in accordance with [RFC5280] (see also [RFC6125]).
954Sheffer, et al. Best Current Practice [Page 17]
956RFC 7525 TLS Recommendations May 2015
961 Section 4.2 above recommends the use of the AES-GCM authenticated
962 encryption algorithm. Please refer to Section 11 of [RFC5246] for
963 general security considerations when using TLS 1.2, and to Section 6
964 of [RFC5288] for security considerations that apply specifically to
965 AES-GCM when used with TLS.
969 Forward secrecy (also called "perfect forward secrecy" or "PFS" and
970 defined in [RFC4949]) is a defense against an attacker who records
971 encrypted conversations where the session keys are only encrypted
972 with the communicating parties' long-term keys. Should the attacker
973 be able to obtain these long-term keys at some point later in time,
974 the session keys and thus the entire conversation could be decrypted.
975 In the context of TLS and DTLS, such compromise of long-term keys is
976 not entirely implausible. It can happen, for example, due to:
978 o A client or server being attacked by some other attack vector, and
979 the private key retrieved.
981 o A long-term key retrieved from a device that has been sold or
982 otherwise decommissioned without prior wiping.
984 o A long-term key used on a device as a default key [Heninger2012].
986 o A key generated by a trusted third party like a CA, and later
987 retrieved from it either by extortion or compromise
990 o A cryptographic break-through, or the use of asymmetric keys with
991 insufficient length [Kleinjung2010].
993 o Social engineering attacks against system administrators.
995 o Collection of private keys from inadequately protected backups.
997 Forward secrecy ensures in such cases that it is not feasible for an
998 attacker to determine the session keys even if the attacker has
999 obtained the long-term keys some time after the conversation. It
1000 also protects against an attacker who is in possession of the long-
1001 term keys but remains passive during the conversation.
1003 Forward secrecy is generally achieved by using the Diffie-Hellman
1004 scheme to derive session keys. The Diffie-Hellman scheme has both
1005 parties maintain private secrets and send parameters over the network
1006 as modular powers over certain cyclic groups. The properties of the
1010Sheffer, et al. Best Current Practice [Page 18]
1012RFC 7525 TLS Recommendations May 2015
1015 so-called Discrete Logarithm Problem (DLP) allow the parties to
1016 derive the session keys without an eavesdropper being able to do so.
1017 There is currently no known attack against DLP if sufficiently large
1018 parameters are chosen. A variant of the Diffie-Hellman scheme uses
1019 Elliptic Curves instead of the originally proposed modular
1022 Unfortunately, many TLS/DTLS cipher suites were defined that do not
1023 feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This
1024 document therefore advocates strict use of forward-secrecy-only
10276.4. Diffie-Hellman Exponent Reuse
1029 For performance reasons, many TLS implementations reuse Diffie-
1030 Hellman and Elliptic Curve Diffie-Hellman exponents across multiple
1031 connections. Such reuse can result in major security issues:
1033 o If exponents are reused for too long (e.g., even more than a few
1034 hours), an attacker who gains access to the host can decrypt
1035 previous connections. In other words, exponent reuse negates the
1036 effects of forward secrecy.
1038 o TLS implementations that reuse exponents should test the DH public
1039 key they receive for group membership, in order to avoid some
1040 known attacks. These tests are not standardized in TLS at the
1041 time of writing. See [RFC6989] for recipient tests required of
1042 IKEv2 implementations that reuse DH exponents.
10446.5. Certificate Revocation
1046 The following considerations and recommendations represent the
1047 current state of the art regarding certificate revocation, even
1048 though no complete and efficient solution exists for the problem of
1049 checking the revocation status of common public key certificates
1052 o Although Certificate Revocation Lists (CRLs) are the most widely
1053 supported mechanism for distributing revocation information, they
1054 have known scaling challenges that limit their usefulness (despite
1055 workarounds such as partitioned CRLs and delta CRLs).
1057 o Proprietary mechanisms that embed revocation lists in the Web
1058 browser's configuration database cannot scale beyond a small
1059 number of the most heavily used Web servers.
1066Sheffer, et al. Best Current Practice [Page 19]
1068RFC 7525 TLS Recommendations May 2015
1071 o The On-Line Certification Status Protocol (OCSP) [RFC6960]
1072 presents both scaling and privacy issues. In addition, clients
1073 typically "soft-fail", meaning that they do not abort the TLS
1074 connection if the OCSP server does not respond. (However, this
1075 might be a workaround to avoid denial-of-service attacks if an
1076 OCSP responder is taken offline.)
1078 o The TLS Certificate Status Request extension (Section 8 of
1079 [RFC6066]), commonly called "OCSP stapling", resolves the
1080 operational issues with OCSP. However, it is still ineffective in
1081 the presence of a MITM attacker because the attacker can simply
1082 ignore the client's request for a stapled OCSP response.
1084 o OCSP stapling as defined in [RFC6066] does not extend to
1085 intermediate certificates used in a certificate chain. Although
1086 the Multiple Certificate Status extension [RFC6961] addresses this
1087 shortcoming, it is a recent addition without much deployment.
1089 o Both CRLs and OCSP depend on relatively reliable connectivity to
1090 the Internet, which might not be available to certain kinds of
1091 nodes (such as newly provisioned devices that need to establish a
1092 secure connection in order to boot up for the first time).
1094 With regard to common public key certificates, servers SHOULD support
1095 the following as a best practice given the current state of the art
1096 and as a foundation for a possible future solution:
1100 2. Both the status_request extension defined in [RFC6066] and the
1101 status_request_v2 extension defined in [RFC6961] (This might
1102 enable interoperability with the widest range of clients.)
1104 3. The OCSP stapling extension defined in [RFC6961]
1106 The considerations in this section do not apply to scenarios where
1107 the DANE-TLSA resource record [RFC6698] is used to signal to a client
1108 which certificate a server considers valid and good to use for TLS
1122Sheffer, et al. Best Current Practice [Page 20]
1124RFC 7525 TLS Recommendations May 2015
11297.1. Normative References
1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1132 Requirement Levels", BCP 14, RFC 2119, March 1997,
1133 <http://www.rfc-editor.org/info/rfc2119>.
1135 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
1136 <http://www.rfc-editor.org/info/rfc2818>.
1138 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1139 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1140 RFC 3766, April 2004,
1141 <http://www.rfc-editor.org/info/rfc3766>.
1143 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
1144 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
1145 for Transport Layer Security (TLS)", RFC 4492, May 2006,
1146 <http://www.rfc-editor.org/info/rfc4492>.
1148 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
1149 36, RFC 4949, August 2007,
1150 <http://www.rfc-editor.org/info/rfc4949>.
1152 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1153 (TLS) Protocol Version 1.2", RFC 5246, August 2008,
1154 <http://www.rfc-editor.org/info/rfc5246>.
1156 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1157 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1158 August 2008, <http://www.rfc-editor.org/info/rfc5288>.
1160 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1161 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1162 August 2008, <http://www.rfc-editor.org/info/rfc5289>.
1164 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
1165 "Transport Layer Security (TLS) Renegotiation Indication
1166 Extension", RFC 5746, February 2010,
1167 <http://www.rfc-editor.org/info/rfc5746>.
1169 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1170 Extensions: Extension Definitions", RFC 6066, January
1171 2011, <http://www.rfc-editor.org/info/rfc6066>.
1178Sheffer, et al. Best Current Practice [Page 21]
1180RFC 7525 TLS Recommendations May 2015
1183 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1184 Verification of Domain-Based Application Service Identity
1185 within Internet Public Key Infrastructure Using X.509
1186 (PKIX) Certificates in the Context of Transport Layer
1187 Security (TLS)", RFC 6125, March 2011,
1188 <http://www.rfc-editor.org/info/rfc6125>.
1190 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
1191 (SSL) Version 2.0", RFC 6176, March 2011,
1192 <http://www.rfc-editor.org/info/rfc6176>.
1194 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1195 Security Version 1.2", RFC 6347, January 2012,
1196 <http://www.rfc-editor.org/info/rfc6347>.
1198 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
1199 February 2015, <http://www.rfc-editor.org/info/rfc7465>.
12017.2. Informative References
1204 bettercrypto.org, "Applied Crypto Hardening", April 2015,
1205 <https://bettercrypto.org/static/
1206 applied-crypto-hardening.pdf>.
1209 CA/Browser Forum, "Baseline Requirements for the Issuance
1210 and Management of Publicly-Trusted Certificates Version
1211 1.1.6", 2013, <https://www.cabforum.org/documents.html>.
1214 Dukhovni, V. and W. Hardaker, "SMTP security via
1215 opportunistic DANE TLS", Work in Progress, draft-ietf-
1216 dane-smtp-with-dane-16, April 2015.
1218 [DANE-SRV] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
1219 Based Authentication of Named Entities (DANE) TLSA Records
1220 with SRV Records", Work in Progress,
1221 draft-ietf-dane-srv-14, April 2015.
1224 Barnes, R., Thomson, M., Pironti, A., and A. Langley,
1225 "Deprecating Secure Sockets Layer Version 3.0", Work in
1226 Progress, draft-ietf-tls-sslv3-diediedie-03, April 2015.
1234Sheffer, et al. Best Current Practice [Page 22]
1236RFC 7525 TLS Recommendations May 2015
1240 Degabriele, J. and K. Paterson, "Attacking the IPsec
1241 Standards in Encryption-only Configurations", IEEE
1242 Symposium on Security and Privacy (SP '07), 2007,
1243 <http://dx.doi.org/10.1109/SP.2007.8>.
1246 Smart, N., "ECRYPT II Yearly Report on Algorithms and
1247 Keysizes (2011-2012)", 2012,
1248 <http://www.ecrypt.eu.org/ecrypt2/>.
1251 Heninger, N., Durumeric, Z., Wustrow, E., and J.
1252 Halderman, "Mining Your Ps and Qs: Detection of Widespread
1253 Weak Keys in Network Devices", Usenix Security Symposium
1256 [IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters",
1257 <http://www.iana.org/assignments/tls-parameters>.
1260 Kleinjung, T., "Factorization of a 768-Bit RSA modulus",
1261 CRYPTO 10, 2010, <https://eprint.iacr.org/2010/006.pdf>.
1264 Krawczyk, H., "The Order of Encryption and Authentication
1265 for Protecting Communications (Or: How Secure is SSL?)",
1267 <https://www.iacr.org/archive/crypto2001/21390309.pdf>.
1269 [Multiple-Encryption]
1270 Merkle, R. and M. Hellman, "On the security of multiple
1271 encryption", Communications of the ACM, Vol. 24, 1981,
1272 <http://dl.acm.org/citation.cfm?id=358718>.
1275 Barker, E., Chen, L., Roginsky, A., and M. Smid,
1276 "Recommendation for Pair-Wise Key Establishment Schemes
1277 Using Discrete Logarithm Cryptography", NIST Special
1278 Publication 800-56A, 2013,
1279 <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
1280 NIST.SP.800-56Ar2.pdf>.
1282 [POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE
1283 Attack", Alert TA14-290A, October 2014,
1284 <https://www.us-cert.gov/ncas/alerts/TA14-290A>.
1290Sheffer, et al. Best Current Practice [Page 23]
1292RFC 7525 TLS Recommendations May 2015
1296 Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size
1297 does matter: attacks and proofs for the TLS record
1299 <http://dx.doi.org/10.1007/978-3-642-25385-0_20>.
1301 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1302 3", BCP 9, RFC 2026, October 1996,
1303 <http://www.rfc-editor.org/info/rfc2026>.
1305 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1306 RFC 2246, January 1999,
1307 <http://www.rfc-editor.org/info/rfc2246>.
1309 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
1310 Algorithm and Its Use with IPsec", RFC 3602, September
1311 2003, <http://www.rfc-editor.org/info/rfc3602>.
1313 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1314 (TLS) Protocol Version 1.1", RFC 4346, April 2006,
1315 <http://www.rfc-editor.org/info/rfc4346>.
1317 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1318 Security", RFC 4347, April 2006,
1319 <http://www.rfc-editor.org/info/rfc4347>.
1321 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
1322 "Transport Layer Security (TLS) Session Resumption without
1323 Server-Side State", RFC 5077, January 2008,
1324 <http://www.rfc-editor.org/info/rfc5077>.
1326 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
1327 Encryption", RFC 5116, January 2008,
1328 <http://www.rfc-editor.org/info/rfc5116>.
1330 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1331 Housley, R., and W. Polk, "Internet X.509 Public Key
1332 Infrastructure Certificate and Certificate Revocation List
1333 (CRL) Profile", RFC 5280, May 2008,
1334 <http://www.rfc-editor.org/info/rfc5280>.
1336 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
1337 Curve Cryptography Algorithms", RFC 6090, February 2011,
1338 <http://www.rfc-editor.org/info/rfc6090>.
1340 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
1341 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
1342 August 2011, <http://www.rfc-editor.org/info/rfc6101>.
1346Sheffer, et al. Best Current Practice [Page 24]
1348RFC 7525 TLS Recommendations May 2015
1351 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1352 Protocol (XMPP): Core", RFC 6120, March 2011,
1353 <http://www.rfc-editor.org/info/rfc6120>.
1355 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport
1356 Layer Security (TLS)", RFC 6460, January 2012,
1357 <http://www.rfc-editor.org/info/rfc6460>.
1359 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1360 of Named Entities (DANE) Transport Layer Security (TLS)
1361 Protocol: TLSA", RFC 6698, August 2012,
1362 <http://www.rfc-editor.org/info/rfc6698>.
1364 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
1365 Transport Security (HSTS)", RFC 6797, November 2012,
1366 <http://www.rfc-editor.org/info/rfc6797>.
1368 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
1369 Galperin, S., and C. Adams, "X.509 Internet Public Key
1370 Infrastructure Online Certificate Status Protocol - OCSP",
1371 RFC 6960, June 2013,
1372 <http://www.rfc-editor.org/info/rfc6960>.
1374 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
1375 Multiple Certificate Status Request Extension", RFC 6961,
1376 June 2013, <http://www.rfc-editor.org/info/rfc6961>.
1378 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
1379 Tests for the Internet Key Exchange Protocol Version 2
1380 (IKEv2)", RFC 6989, July 2013,
1381 <http://www.rfc-editor.org/info/rfc6989>.
1383 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1384 Most of the Time", RFC 7435, December 2014,
1385 <http://www.rfc-editor.org/info/rfc7435>.
1387 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
1388 Known Attacks on Transport Layer Security (TLS) and
1389 Datagram TLS (DTLS)", RFC 7457, February 2015,
1390 <http://www.rfc-editor.org/info/rfc7457>.
1392 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
1393 Suite Value (SCSV) for Preventing Protocol Downgrade
1394 Attacks", RFC 7507, April 2015.
1402Sheffer, et al. Best Current Practice [Page 25]
1404RFC 7525 TLS Recommendations May 2015
1408 Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
1409 Langley, A., and M. Ray, "Transport Layer Security (TLS)
1410 Session Hash and Extended Master Secret Extension", Work
1411 in Progress, draft-ietf-tls-session-hash-05, April 2015.
1414 Smith, B., "Proposal to Change the Default TLS
1415 Ciphersuites Offered by Browsers.", 2013,
1416 <https://briansmith.org/browser-ciphersuites-01.html>.
1419 Soghoian, C. and S. Stamm, "Certified lies: Detecting and
1420 defeating government interception attacks against SSL",
1421 Proc. 15th Int. Conf. Financial Cryptography and Data
1424 [TLS-XMPP] Saint-Andre, P. and a. alkemade, "Use of Transport Layer
1425 Security (TLS) in the Extensible Messaging and Presence
1426 Protocol (XMPP)", Work in Progress,
1427 draft-ietf-uta-xmpp-07, April 2015.
1430 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti,
1431 "Triple Handshakes Considered Harmful: Breaking and Fixing
1432 Authentication over TLS", 2014,
1433 <https://secure-resumption.com/>.
1437 Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen
1438 Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson
1439 Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller,
1440 Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom
1441 Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean
1442 Turner, and Aaron Zauner for their feedback and suggested
1443 improvements. Thanks also to Brian Smith, who has provided a great
1444 resource in his "Proposal to Change the Default TLS Ciphersuites
1445 Offered by Browsers" [Smith2013]. Finally, thanks to all others who
1446 commented on the TLS, UTA, and other discussion lists but who are not
1447 mentioned here by name.
1449 Robert Sparks and Dave Waltermire provided helpful reviews on behalf
1450 of the General Area Review Team and the Security Directorate,
1458Sheffer, et al. Best Current Practice [Page 26]
1460RFC 7525 TLS Recommendations May 2015
1463 During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins,
1464 Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick
1465 provided comments that led to further improvements.
1467 Ralph Holz gratefully acknowledges the support by Technische
1468 Universitaet Muenchen. The authors gratefully acknowledge the
1469 assistance of Leif Johansson and Orit Levin as the working group
1470 chairs and Pete Resnick as the sponsoring Area Director.
1477 Hod HaSharon 4524075
1480 EMail: yaronf.ietf@gmail.com
1489 EMail: ralph.ietf@gmail.com
1495 EMail: peter@andyet.com
1496 URI: https://andyet.com/
1514Sheffer, et al. Best Current Practice [Page 27]