draft-ietf-uta-tls-bcp-09.txt   draft-ietf-uta-tls-bcp-10.txt 
UTA Y. Sheffer UTA Y. Sheffer
Internet-Draft Porticor Internet-Draft Intuit
Intended status: Best Current Practice R. Holz Intended status: Best Current Practice R. Holz
Expires: August 15, 2015 TUM Expires: August 24, 2015 TUM
P. Saint-Andre P. Saint-Andre
&yet &yet
February 11, 2015 February 20, 2015
Recommendations for Secure Use of TLS and DTLS Recommendations for Secure Use of TLS and DTLS
draft-ietf-uta-tls-bcp-09 draft-ietf-uta-tls-bcp-10
Abstract Abstract
Transport Layer Security (TLS) and Datagram Transport Layer Security Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are widely used to protect data exchanged over application (DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
last few years, several serious attacks on TLS have emerged, last few years, several serious attacks on TLS have emerged,
including attacks on its most commonly used cipher suites and modes including attacks on its most commonly used cipher suites and their
of operation. This document provides recommendations for improving modes of operation. This document provides recommendations for
the security of deployed services that use TLS and DTLS. The improving the security of deployed services that use TLS and DTLS.
recommendations are applicable to the majority of use cases. The recommendations are applicable to the majority of use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2015. This Internet-Draft will expire on August 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Recommendations . . . . . . . . . . . . . . . . . . . 4 3. General Recommendations . . . . . . . . . . . . . . . . . . . 4
3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 4
3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 4 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 4
3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 5 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 5
3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 6 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 6
3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 7 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 7
3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 7 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 8
3.6. Server Name Indication . . . . . . . . . . . . . . . . . 8 3.6. Server Name Indication . . . . . . . . . . . . . . . . . 8
4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 8 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 8
4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 8 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 8
4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 10 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 10
4.2.1. Implementation Details . . . . . . . . . . . . . . . 10 4.2.1. Implementation Details . . . . . . . . . . . . . . . 11
4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 11 4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 11
4.4. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 12 4.4. Modular vs. Elliptic Curve DH Cipher Suites . . . . . . . 12
4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 13 4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 13
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 13 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 13
5.1. Security Services . . . . . . . . . . . . . . . . . . . . 13 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 14
5.2. Unauthenticated TLS and Opportunistic Security . . . . . 14 5.2. Unauthenticated TLS and Opportunistic Security . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 15 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 16
7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 16 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 17
7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 17 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 18
7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 18 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 24 A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 25
A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 24 A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 25
A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 24 A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 25
A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 24 A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 25
A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 24 A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 26
A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 24 A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 26
A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 25 A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 26
A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 25 A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 26
A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 25 A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 27
A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 25 A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 27
A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 26 A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 27
A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 26 A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Transport Layer Security (TLS) [RFC5246] and Datagram Transport
Security Layer (DTLS) [RFC6347] are widely used to protect data Security Layer (DTLS) [RFC6347] are widely used to protect data
exchanged over application protocols such as HTTP, SMTP, IMAP, POP, exchanged over application protocols such as HTTP, SMTP, IMAP, POP,
SIP, and XMPP. Over the last few years, several serious attacks on SIP, and XMPP. Over the last few years, several serious attacks on
TLS have emerged, including attacks on its most commonly used cipher TLS have emerged, including attacks on its most commonly used cipher
suites and modes of operation. For instance, both the AES-CBC suites and their modes of operation. For instance, both the AES-CBC
[RFC3602] and RC4 [I-D.ietf-tls-prohibiting-rc4] encryption [RFC3602] and RC4 [RFC7465] encryption algorithms, which together
algorithms, which together are the most widely deployed ciphers, have have been the most widely deployed ciphers, have been attacked in the
been attacked in the context of TLS. A companion document [RFC7457] context of TLS. A companion document [RFC7457] provides detailed
provides detailed information about these attacks. information about these attacks and will help the reader understand
the rationale behind the recommendations provided here.
Because of these attacks, those who implement and deploy TLS and DTLS Because of these attacks, those who implement and deploy TLS and DTLS
need updated guidance on how TLS can be used securely. This document need updated guidance on how TLS can be used securely. This document
provides guidance for deployed services as well as for software provides guidance for deployed services as well as for software
implementations, assuming the implementer expects his or her code to implementations, assuming the implementer expects his or her code to
be deployed in environments defined in the following section. In be deployed in environments defined in Section 5. In fact, this
fact, this document calls for the deployment of algorithms that are document calls for the deployment of algorithms that are widely
widely implemented but not yet widely deployed. Concerning implemented but not yet widely deployed. Concerning deployment, this
deployment, this document targets a wide audience, namely all document targets a wide audience, namely all deployers who wish to
deployers who wish to add authentication (be it one-way only or add authentication (be it one-way only or mutual), confidentiality,
mutual), confidentiality, and data integrity protection to their and data integrity protection to their communications.
communications.
The recommendations herein take into consideration the security of The recommendations herein take into consideration the security of
various mechanisms, their technical maturity and interoperability, various mechanisms, their technical maturity and interoperability,
and their prevalence in implementations at the time of writing. and their prevalence in implementations at the time of writing.
Unless it is explicitly called out that a recommendation applies to Unless it is explicitly called out that a recommendation applies to
TLS alone or to DTLS alone, each recommendation applies to both TLS TLS alone or to DTLS alone, each recommendation applies to both TLS
and DTLS. and DTLS.
It is expected that the TLS 1.3 specification will resolve many of It is expected that the TLS 1.3 specification will resolve many of
the vulnerabilities listed in this document. A system that deploys the vulnerabilities listed in this document. A system that deploys
TLS 1.3 will have fewer vulnerabilities than TLS 1.2 or below. This TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below.
document is likely to be updated after TLS 1.3 gets noticeable This document is likely to be updated after TLS 1.3 gets noticeable
deployment. deployment.
These are minimum recommendations for the use of TLS in the vast These are minimum recommendations for the use of TLS in the vast
majority of implementation and deployment scenarios, with the majority of implementation and deployment scenarios, with the
exception of unauthenticated TLS (see Section 5). Other exception of unauthenticated TLS (see Section 5). Other
specifications that reference this document can have stricter specifications that reference this document can have stricter
requirements related to one or more aspects of the protocol, based on requirements related to one or more aspects of the protocol, based on
their particular circumstances (e.g., for use with a particular their particular circumstances (e.g., for use with a particular
application protocol); when that is the case, implementers are application protocol); when that is the case, implementers are
advised to adhere to those stricter requirements. Furthermore, this advised to adhere to those stricter requirements. Furthermore, this
skipping to change at page 5, line 10 skipping to change at page 5, line 10
Rationale: Today, SSLv2 is considered insecure [RFC6176]. Rationale: Today, SSLv2 is considered insecure [RFC6176].
o Implementations MUST NOT negotiate SSL version 3. o Implementations MUST NOT negotiate SSL version 3.
Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and
plugged some significant security holes, but did not support plugged some significant security holes, but did not support
strong cipher suites. SSLv3 does not support TLS extensions, some strong cipher suites. SSLv3 does not support TLS extensions, some
of which (e.g., renegotiation_info) are security-critical. In of which (e.g., renegotiation_info) are security-critical. In
addition, with the emergence of the POODLE attack [POODLE], SSLv3 addition, with the emergence of the POODLE attack [POODLE], SSLv3
is now widely recognized as fundamentally insecure. is now widely recognized as fundamentally insecure. See
[I-D.ietf-tls-sslv3-diediedie] for further details.
o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]. o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]
unless no higher version is available in the negotiation.
Rationale: TLS 1.0 (published in 1999) does not support many Rationale: TLS 1.0 (published in 1999) does not support many
modern, strong cipher suites. In addition, TLS 1.0 lacks a per- modern, strong cipher suites. In addition, TLS 1.0 lacks a per-
record IV for CBC-based cipher suites and does not warn against record IV for CBC-based cipher suites and does not warn against
common padding errors. common padding errors.
o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]. o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]
unless no higher version is available in the negotiation.
Rationale: TLS 1.1 (published in 2006) is a security improvement Rationale: TLS 1.1 (published in 2006) is a security improvement
over TLS 1.0, but still does not support certain stronger cipher over TLS 1.0, but still does not support certain stronger cipher
suites. suites.
o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
negotiate TLS version 1.2 over earlier versions of TLS. negotiate TLS version 1.2 over earlier versions of TLS.
Rationale: Several stronger cipher suites are available only with Rationale: Several stronger cipher suites are available only with
TLS 1.2 (published in 2008). In fact, the cipher suites TLS 1.2 (published in 2008). In fact, the cipher suites
skipping to change at page 5, line 50 skipping to change at page 6, line 5
1.1 was published. The following are the recommendations with 1.1 was published. The following are the recommendations with
respect to DTLS: respect to DTLS:
o Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347]. o Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347].
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above). Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
o Implementations MUST support, and prefer to negotiate, DTLS o Implementations MUST support, and prefer to negotiate, DTLS
version 1.2 [RFC6347]. version 1.2 [RFC6347].
Version 1.2 of DTLS correlates to Version 1.2 of TLS 1.2 (see Version 1.2 of DTLS correlates to Version 1.2 of TLS (see above).
above). (There is no Version 1.1 of DTLS.) (There is no Version 1.1 of DTLS.)
3.1.3. Fallback to Lower Versions 3.1.3. Fallback to Lower Versions
Clients that "fall back" to lower versions of the protocol after the Clients that "fall back" to lower versions of the protocol after the
server rejects higher versions of the protocol MUST NOT fall back to server rejects higher versions of the protocol MUST NOT fall back to
SSLv3 or earlier. SSLv3 or earlier.
Rationale: Some client implementations revert to lower versions of Rationale: Some client implementations revert to lower versions of
TLS or even to SSLv3 if the server rejected higher versions of the TLS or even to SSLv3 if the server rejected higher versions of the
protocol. This fallback can be forced by a man in the middle (MITM) protocol. This fallback can be forced by a man in the middle (MITM)
attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS
1.2, the version recommended by this document. While TLS 1.0-only 1.2, the version recommended by this document. While TLS 1.0-only
servers are still quite common, IP scans show that SSLv3-only servers servers are still quite common, IP scans show that SSLv3-only servers
amount to only about 3% of the current Web server population. (At amount to only about 3% of the current Web server population. (At
the time of this writing, an explicit method for preventing downgrade the time of this writing, an explicit method for preventing downgrade
attacks is being defined in [I-D.ietf-tls-downgrade-scsv].) attacks is being defined in [I-D.ietf-tls-downgrade-scsv].)
3.2. Strict TLS 3.2. Strict TLS
To prevent SSL Stripping: The following recommendations are provided to help prevent SSL
Stripping (the attack is summarized in Section 2.1 of [RFC7457]):
o In cases where an application protocol allows implementations or o In cases where an application protocol allows implementations or
deployments a choice between strict TLS configuration and dynamic deployments a choice between strict TLS configuration and dynamic
upgrade from unencrypted to TLS-protected traffic (such as upgrade from unencrypted to TLS-protected traffic (such as
STARTTLS), clients and servers SHOULD prefer strict TLS STARTTLS), clients and servers SHOULD prefer strict TLS
configuration. configuration.
o Application protocols typically provide a way for the server to o Application protocols typically provide a way for the server to
offer TLS during an initial protocol exchange, and sometimes also offer TLS during an initial protocol exchange, and sometimes also
provide a way for the server to advertise support for TLS (e.g., provide a way for the server to advertise support for TLS (e.g.,
through a flag indicating that TLS is required); unfortunately, through a flag indicating that TLS is required); unfortunately,
these indications are sent before the communication channel is these indications are sent before the communication channel is
encrypted. A client SHOULD attempt to negotiate TLS even if these encrypted. A client SHOULD attempt to negotiate TLS even if these
indications are not communicated by the server. indications are not communicated by the server.
o HTTP client and server implementations MUST support the HTTP o HTTP client and server implementations MUST support the HTTP
Strict Transport Security (HSTS) header [RFC6797], in order to Strict Transport Security (HSTS) header [RFC6797], in order to
allow Web servers to advertise that they are willing to accept allow Web servers to advertise that they are willing to accept
TLS-only clients. TLS-only clients.
o When applicable, Web servers SHOULD use HSTS to indicate that they o Web servers SHOULD use HSTS to indicate that they are willing to
are willing to accept TLS-only clients. accept TLS-only clients, unless they are deployed in such a way
that using HSTS would in fact weaken overall security (e.g., it
can be problematic to use HSTS with self-signed certificates, as
described in Section 11.3 of [RFC6797]).
Rationale: Combining unprotected and TLS-protected communication Rationale: Combining unprotected and TLS-protected communication
opens the way to SSL Stripping and similar attacks, since an initial opens the way to SSL Stripping and similar attacks, since an initial
part of the communication is not integrity protected and therefore part of the communication is not integrity protected and therefore
can be manipulated by an attacker whose goal is to keep the can be manipulated by an attacker whose goal is to keep the
communication in the clear. communication in the clear.
3.3. Compression 3.3. Compression
Implementations and deployments SHOULD disable TLS-level compression In order to help prevent compression-related attacks (summarized in
([RFC5246], Section 6.2.2). Section 2.6 of [RFC7457]), implementations and deployments SHOULD
disable TLS-level compression ([RFC5246], Section 6.2.2), unless the
application protocol in question has been shown not to be open to
such attacks.
Rationale: TLS compression has been subject to security attacks, such Rationale: TLS compression has been subject to security attacks, such
as the CRIME attack. as the CRIME attack.
Implementers should note that compression at higher protocol levels Implementers should note that compression at higher protocol levels
can allow an active attacker to extract cleartext information from can allow an active attacker to extract cleartext information from
the connection. The BREACH attack is one such case. These issues the connection. The BREACH attack is one such case. These issues
can only be mitigated outside of TLS and are thus out of scope of the can only be mitigated outside of TLS and are thus out of scope of the
current document. See Section 2.6 of [RFC7457] for further details. current document. See Section 2.6 of [RFC7457] for further details.
skipping to change at page 7, line 51 skipping to change at page 8, line 11
the TLS endpoint (either client or server) and its secrets from the TLS endpoint (either client or server) and its secrets from
reading either past or future communication. The tickets must be reading either past or future communication. The tickets must be
managed so as not to negate this security property. managed so as not to negate this security property.
3.5. TLS Renegotiation 3.5. TLS Renegotiation
Where handshake renegotiation is implemented, both clients and Where handshake renegotiation is implemented, both clients and
servers MUST implement the renegotiation_info extension, as defined servers MUST implement the renegotiation_info extension, as defined
in [RFC5746]. in [RFC5746].
To counter the Triple Handshake attack, the recommended The most secure option for countering the Triple Handshake attack is
countermeasures from [triple-handshake] are adopted: TLS clients to refuse any change of certificates during renegotiation. In
SHOULD apply the same validation policy for all certificates received addition, TLS clients SHOULD apply the same validation policy for all
over a connection, bind the master secret to the full handshake, and certificates received over a connection. The [triple-handshake]
bind the abbreviated session resumption handshake to the original document suggests several other possible countermeasures, such as
full handshake. In some usages, the most secure option might be to binding the master secret to the full handshake (see
refuse any change of certificates during renegotiation. [I-D.ietf-tls-session-hash]) and binding the abbreviated session
resumption handshake to the original full handshake. Although the
latter two techniques are still under development and thus do not
qualify as current practices, those who implement and deploy TLS are
advised to watch for further development of appropriate
countermeasures.
3.6. Server Name Indication 3.6. Server Name Indication
TLS implementations MUST support the Server Name Indication (SNI) TLS implementations MUST support the Server Name Indication (SNI)
extension for those higher level protocols which would benefit from extension defined in Section 3 of [RFC6066] for those higher level
it, including HTTPS. However, unlike implementation, the use of SNI protocols which would benefit from it, including HTTPS. However,
in particular circumstances is a matter of local policy. unlike implementation, the use of SNI in particular circumstances is
a matter of local policy.
Rationale: SNI supports deployment of multiple TLS-protected virtual Rationale: SNI supports deployment of multiple TLS-protected virtual
servers on a single address, and therefore enables fine-grained servers on a single address, and therefore enables fine-grained
security for these virtual servers, by allowing each one to have its security for these virtual servers, by allowing each one to have its
own certificate. own certificate.
4. Recommendations: Cipher Suites 4. Recommendations: Cipher Suites
TLS and its implementations provide considerable flexibility in the TLS and its implementations provide considerable flexibility in the
selection of cipher suites. Unfortunately, some available cipher selection of cipher suites. Unfortunately, some available cipher
skipping to change at page 9, line 10 skipping to change at page 9, line 24
provide no confidentiality services. Any entity in the network provide no confidentiality services. Any entity in the network
with access to the connection can view the plaintext of contents with access to the connection can view the plaintext of contents
being exchanged by the client and server. (Nevertheless, this being exchanged by the client and server. (Nevertheless, this
document does not discourage software from implementing NULL document does not discourage software from implementing NULL
cipher suites, since they can be useful for testing and cipher suites, since they can be useful for testing and
debugging.) debugging.)
o Implementations MUST NOT negotiate RC4 cipher suites. o Implementations MUST NOT negotiate RC4 cipher suites.
Rationale: The RC4 stream cipher has a variety of cryptographic Rationale: The RC4 stream cipher has a variety of cryptographic
weaknesses, as documented in [I-D.ietf-tls-prohibiting-rc4]. Note weaknesses, as documented in [RFC7465]. Note that DTLS
that DTLS specifically forbids the use of RC4 already. specifically forbids the use of RC4 already.
o Implementations MUST NOT negotiate cipher suites offering less o Implementations MUST NOT negotiate cipher suites offering less
than 112 bits of security, including the so-called "export-level" than 112 bits of security, including so-called "export-level"
encryption (which provide 40 or 56 bits of security). encryption (which provide 40 or 56 bits of security).
Rationale: Based on [RFC3766], at least 112 bits of security is Rationale: Based on [RFC3766], at least 112 bits of security is
needed. 40-bit and 56-bit security are considered insecure today. needed. 40-bit and 56-bit security are considered insecure today.
TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers. TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers.
o Implementations SHOULD NOT negotiate cipher suites that use o Implementations SHOULD NOT negotiate cipher suites that use
algorithms offering less than 128 bits of security. algorithms offering less than 128 bits of security.
Rationale: Cipher suites that offer between 112-bits and 128-bits Rationale: Cipher suites that offer between 112-bits and 128-bits
of security are not considered weak at this time, however it is of security are not considered weak at this time, however it is
expected that their useful lifespan is short enough to justify expected that their useful lifespan is short enough to justify
supporting stronger cipher suites at this time. 128-bit ciphers supporting stronger cipher suites at this time. 128-bit ciphers
are expected to remain secure for at least several years, and are expected to remain secure for at least several years, and
256-bit ciphers "until the next fundamental technology 256-bit ciphers until the next fundamental technology
breakthrough". Note that, because of so-called "meet-in-the- breakthrough. Note that, because of so-called "meet-in-the-
middle" attacks [Multiple-Encryption] some legacy cipher suites middle" attacks [Multiple-Encryption] some legacy cipher suites
(e.g., 168-bit 3DES) have an effective key length which is smaller (e.g., 168-bit 3DES) have an effective key length which is smaller
than their nominal key length (112 bits in the case of 3DES). than their nominal key length (112 bits in the case of 3DES).
Such cipher suites should be evaluated according to their Such cipher suites should be evaluated according to their
effective key length. effective key length.
o Implementations MUST support, and SHOULD prefer to negotiate, o Implementations SHOULD NOT negotiate cipher suites based on RSA
cipher suites offering forward secrecy, such as those in the key transport, a.k.a. "static RSA".
Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie-
Hellman ("DHE" and "ECDHE") families. Rationale: These cipher suites, which have assigned values
starting with the string "TLS_RSA_WITH_*", have several drawbacks,
especially the fact that they do not support forward secrecy.
o Implementations MUST support and prefer to negotiate, cipher
suites offering forward secrecy, such as those in the Ephemeral
Diffie-Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE"
and "ECDHE") families.
Rationale: Forward secrecy (sometimes called "perfect forward Rationale: Forward secrecy (sometimes called "perfect forward
secrecy") prevents the recovery of information that was encrypted secrecy") prevents the recovery of information that was encrypted
with older session keys, thus limiting the amount of time during with older session keys, thus limiting the amount of time during
which attacks can be successful. See Section 7.3 for a detailed which attacks can be successful. See Section 7.3 for a detailed
discussion. discussion.
4.2. Recommended Cipher Suites 4.2. Recommended Cipher Suites
Given the foregoing considerations, implementation and deployment of Given the foregoing considerations, implementation and deployment of
skipping to change at page 10, line 22 skipping to change at page 10, line 40
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
These cipher suites are supported only in TLS 1.2 because they are These cipher suites are supported only in TLS 1.2 because they are
authenticated encryption (AEAD) algorithms [RFC5116]. authenticated encryption (AEAD) algorithms [RFC5116].
Typically, in order to prefer these suites, the order of suites needs Typically, in order to prefer these suites, the order of suites needs
to be explicitly configured in server software. It would be ideal if to be explicitly configured in server software (see [BETTERCRYPTO]
server software implementations were to prefer these suites by for helpful deployment guidelines, but note that its recommendations
differ from the current document in some details). It would be ideal
if server software implementations were to prefer these suites by
default. default.
Some devices have hardware support for AES-CCM but not AES-GCM, so Some devices have hardware support for AES-CCM but not AES-GCM, so
they are unable to follow the foregoing recommendations regarding they are unable to follow the foregoing recommendations regarding
cipher suites. There are even devices that do not support public key cipher suites. There are even devices that do not support public key
cryptography at all, but they are out of scope entirely. cryptography at all, but they are out of scope entirely.
4.2.1. Implementation Details 4.2.1. Implementation Details
Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the
first proposal to any server, unless they have prior knowledge that first proposal to any server, unless they have prior knowledge that
the server cannot respond to a TLS 1.2 client_hello message. the server cannot respond to a TLS 1.2 client_hello message.
Servers SHOULD prefer this cipher suite over weaker cipher suites Servers MUST prefer this cipher suite over weaker cipher suites
whenever it is proposed, even if it is not the first proposal. whenever it is proposed, even if it is not the first proposal.
Clients are of course free to offer stronger cipher suites, e.g., Clients are of course free to offer stronger cipher suites, e.g.,
using AES-256; when they do, the server SHOULD prefer the stronger using AES-256; when they do, the server SHOULD prefer the stronger
cipher suite unless there are compelling reasons (e.g., seriously cipher suite unless there are compelling reasons (e.g., seriously
degraded performance) to choose otherwise. degraded performance) to choose otherwise.
This document does not change the mandatory-to-implement TLS cipher This document does not change the mandatory-to-implement TLS cipher
suite(s) prescribed by TLS or application protocols using TLS. To suite(s) prescribed by TLS. To maximize interoperability, RFC 5246
maximize interoperability, RFC 5246 mandates implementation of the mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly suite, which is significantly weaker than the cipher suites
weaker than the cipher suites recommended here (the GCM mode does not recommended here (the GCM mode does not suffer from the same
suffer from the same weakness, caused by the order of MAC-then- weakness, caused by the order of MAC-then-Encrypt in TLS
Encrypt in TLS [Krawczyk2001], since it uses an Authenticated [Krawczyk2001], since it uses an Authenticated Encryption with
Encryption with Associated Data (AEAD) mode of operation). Associated Data (AEAD) mode of operation). Implementers should
consider the interoperability gain against the loss in security when
Implementers should consider the interoperability gain against the deploying the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. Other
loss in security when deploying that cipher suite. Other application application protocols specify other cipher suites as mandatory to
protocols specify other cipher suites as mandatory to implement implement (MTI).
(MTI).
Note that some profiles of TLS 1.2 use different cipher suites. For Note that some profiles of TLS 1.2 use different cipher suites. For
example, [RFC6460] defines a profile that uses the example, [RFC6460] defines a profile that uses the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.
[RFC4492] allows clients and servers to negotiate ECDH parameters [RFC4492] allows clients and servers to negotiate ECDH parameters
(curves). Both clients and servers SHOULD include the "Supported (curves). Both clients and servers SHOULD include the "Supported
Elliptic Curves" extension [RFC4492]. For interoperability, clients Elliptic Curves" extension [RFC4492]. For interoperability, clients
and servers SHOULD support the NIST P-256 (secp256r1) curve and servers SHOULD support the NIST P-256 (secp256r1) curve
skipping to change at page 12, line 20 skipping to change at page 12, line 41
TLS 1.2. TLS 1.2.
4.4. Modular vs. Elliptic Curve DH Cipher Suites 4.4. Modular vs. Elliptic Curve DH Cipher Suites
Not all TLS implementations support both modular and elliptic curve Not all TLS implementations support both modular and elliptic curve
Diffie-Hellman groups, as required by Section 4.2. Some Diffie-Hellman groups, as required by Section 4.2. Some
implementations are severely limited in the length of DH values. implementations are severely limited in the length of DH values.
When such implementations need to be accommodated, the following are When such implementations need to be accommodated, the following are
RECOMMENDED (in priority order): RECOMMENDED (in priority order):
1. Elliptic Curve DHE with negotiated parameters [RFC5289] 1. Elliptic Curve DHE with appropriately negotiated parameters
(e.g., the curve to be used) and a MAC algorithm stronger than
HMAC-SHA1 [RFC5289]
2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit 2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit
Diffie-Hellman parameters Diffie-Hellman parameters
3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters. 3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters.
Rationale: Although Elliptic Curve Cryptography is widely deployed Rationale: Although Elliptic Curve Cryptography is widely deployed
there are some communities where its uptake has been limited for there are some communities where its uptake has been limited for
several reasons, including its complexity compared to modular several reasons, including its complexity compared to modular
arithmetic and longstanding perceptions of IPR concerns (which, for arithmetic and longstanding perceptions of IPR concerns (which, for
skipping to change at page 13, line 22 skipping to change at page 13, line 44
Implementations MUST NOT use the Truncated HMAC extension, defined in Implementations MUST NOT use the Truncated HMAC extension, defined in
Section 7 of [RFC6066]. Section 7 of [RFC6066].
Rationale: the extension does not apply to the AEAD cipher suites Rationale: the extension does not apply to the AEAD cipher suites
recommended above. However it does apply to most other TLS cipher recommended above. However it does apply to most other TLS cipher
suites. Its use has been shown to be insecure in [PatersonRS11]. suites. Its use has been shown to be insecure in [PatersonRS11].
5. Applicability Statement 5. Applicability Statement
The deployment recommendations of this document address the operators The recommendations of this document primarily apply to the
of application layer services that are most commonly used on the implementation and deployment of application protocols that are most
Internet, including, but not limited to: commonly used with TLS and DTLS on the Internet today. Examples
include, but are not limited to:
o Operators of web services that wish to protect HTTP with TLS. o Web software and services that wish to protect HTTP traffic with
TLS.
o Operators of email services who wish to protect the application- o Email software and services that wish to protect IMAP, POP3, or
layer protocols with TLS (e.g., IMAP, POP3 or SMTP). SMTP traffic with TLS.
o Operators of instant-messaging services who wish to protect their o Instant-messaging software and services that wish to protect XMPP
application-layer protocols with TLS (e.g., XMPP or IRC). or IRC traffic with TLS.
o Realtime media software and services that wish to protect SRTP
traffic with DTLS.
This document does not modify the implementation and deployment
recommendations (e.g., mandatory-to-implement cipher suites)
prescribed by existing application protocols that employ TLS or DTLS.
If the community that uses such an application protocol wishes to
modernize its usage of TLS or DTLS to be consistent with the best
practices recommended here, it needs to explicitly update the
existing application protocol definition (one example is
[I-D.ietf-uta-xmpp], which updates [RFC6120]).
Designers of new application protocols developed through the Internet
Standards Process are expected to conform to the best practices
recommended here, unless they provide documentation of compelling
reasons that would prevent such conformance (e.g., widespread
deployment on constrained devices that lack support for the necessary
algorithms).
5.1. Security Services 5.1. Security Services
This document provides recommendations for an audience that wishes to This document provides recommendations for an audience that wishes to
secure their communication with TLS to achieve the following: secure their communication with TLS to achieve the following:
o Confidentiality: all application-layer communication is encrypted o Confidentiality: all application-layer communication is encrypted
with the goal that no party should be able to decrypt it except with the goal that no party should be able to decrypt it except
the intended receiver. the intended receiver.
skipping to change at page 18, line 11 skipping to change at page 18, line 52
known attacks. These tests are not standardized in TLS at the known attacks. These tests are not standardized in TLS at the
time of writing. See [RFC6989] for recipient tests required of time of writing. See [RFC6989] for recipient tests required of
IKEv2 implementations that reuse DH exponents. IKEv2 implementations that reuse DH exponents.
7.5. Certificate Revocation 7.5. Certificate Revocation
The following considerations and recommendations represent the The following considerations and recommendations represent the
current state of the art regarding certificate revocation, even current state of the art regarding certificate revocation, even
though no complete and efficient solution exists for the problem of though no complete and efficient solution exists for the problem of
checking the revocation status of common public key certificates checking the revocation status of common public key certificates
(a.k.a. PKIX certificates, [RFC5280]): [RFC5280]:
o Although Certificate Revocation Lists (CRLs) are the most widely o Although Certificate Revocation Lists (CRLs) are the most widely
supported mechanism for distributing revocation information, they supported mechanism for distributing revocation information, they
have known scaling challenges that limit their usefulness (despite have known scaling challenges that limit their usefulness (despite
workarounds such as partitioned CRLS and delta CRLs). workarounds such as partitioned CRLS and delta CRLs).
o Proprietary mechanisms that embed revocation lists in the Web o Proprietary mechanisms that embed revocation lists in the Web
browser's configuration database cannot scale beyond a small browser's configuration database cannot scale beyond a small
number of the most heavily used Web servers. number of the most heavily used Web servers.
skipping to change at page 18, line 44 skipping to change at page 19, line 36
o OCSP stapling as defined in [RFC6066] does not extend to o OCSP stapling as defined in [RFC6066] does not extend to
intermediate certificates used in a certificate chain. Although intermediate certificates used in a certificate chain. Although
[RFC6961] addresses this shortcoming, it is a recent addition [RFC6961] addresses this shortcoming, it is a recent addition
without much deployment. without much deployment.
o Both CRLs and OSCP depend on relatively reliable connectivity to o Both CRLs and OSCP depend on relatively reliable connectivity to
the Internet, which might not be available to certain kinds of the Internet, which might not be available to certain kinds of
nodes (such as newly provisioned devices that need to establish a nodes (such as newly provisioned devices that need to establish a
secure connection in order to boot up for the first time). secure connection in order to boot up for the first time).
With regard to PKIX certificates, servers SHOULD support the With regard to common public key certificates, servers SHOULD support
following as a best practice given the current state of the art and the following as a best practice given the current state of the art
as a foundation for a possible future solution: and as a foundation for a possible future solution:
1. OCSP [RFC6960] 1. OCSP [RFC6960]
2. Both the status_request extension defined in [RFC6066] and the 2. Both the status_request extension defined in [RFC6066] and the
status_request_v2 extension defined in [RFC6961] (this might status_request_v2 extension defined in [RFC6961] (this might
enable interoperability with the widest range of clients) enable interoperability with the widest range of clients)
3. The OCSP stapling extension defined in [RFC6961] 3. The OCSP stapling extension defined in [RFC6961]
The foregoing considerations do not apply to scenarios where the The considerations in this section do not apply to scenarios where
DANE-TLSA resource record [RFC6698] is used to signal to a client the DANE-TLSA resource record [RFC6698] is used to signal to a client
which certificate a server considers valid and good to use for TLS which certificate a server considers valid and good to use for TLS
connections. connections.
8. Acknowledgments 8. Acknowledgments
Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen
Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson
Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller,
Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom
Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean
skipping to change at page 19, line 30 skipping to change at page 20, line 23
improvements. Thanks also to Brian Smith, who has provided a great improvements. Thanks also to Brian Smith, who has provided a great
resource in his "Proposal to Change the Default TLS Ciphersuites resource in his "Proposal to Change the Default TLS Ciphersuites
Offered by Browsers" [Smith2013]. Finally, thanks to all others who Offered by Browsers" [Smith2013]. Finally, thanks to all others who
commented on the TLS, UTA, and other discussion lists but who are not commented on the TLS, UTA, and other discussion lists but who are not
mentioned here by name. mentioned here by name.
Robert Sparks and Dave Waltermire provided helpful reviews on behalf Robert Sparks and Dave Waltermire provided helpful reviews on behalf
of the General Area Review Team and the Security Directorate, of the General Area Review Team and the Security Directorate,
respectively. respectively.
During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins,
Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick
provided comments that led to further improvements.
The authors gratefully acknowledge the assistance of Leif Johansson The authors gratefully acknowledge the assistance of Leif Johansson
and Orit Levin as the working group chairs and Pete Resnick as the and Orit Levin as the working group chairs and Pete Resnick as the
sponsoring Area Director. sponsoring Area Director.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tls-prohibiting-rc4]
Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
tls-prohibiting-rc4-01 (work in progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004. RFC 3766, April 2004.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008. August 2008.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication "Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010. Extension", RFC 5746, February 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011. (SSL) Version 2.0", RFC 6176, March 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
February 2015.
9.2. Informative References 9.2. Informative References
[BETTERCRYPTO]
bettercrypto.org, , "Applied Crypto Hardening", 2015,
<https://bettercrypto.org/static/applied-crypto-
hardening.pdf>.
[CAB-Baseline] [CAB-Baseline]
CA/Browser Forum, , "Baseline Requirements for the CA/Browser Forum, , "Baseline Requirements for the
Issuance and Management of Publicly-Trusted Certificates Issuance and Management of Publicly-Trusted Certificates
Version 1.1.6", 2013, <https://www.cabforum.org/ Version 1.1.6", 2013, <https://www.cabforum.org/
documents.html>. documents.html>.
[DegabrieleP07] [DegabrieleP07]
Degabriele, J. and K. Paterson, "Attacking the IPsec Degabriele, J. and K. Paterson, "Attacking the IPsec
standards in encryption-only configurations", 2007, standards in encryption-only configurations", 2007,
<http://dx.doi.org/10.1109/SP.2007.8>. <http://dx.doi.org/10.1109/SP.2007.8>.
skipping to change at page 21, line 28 skipping to change at page 22, line 33
Based Authentication of Named Entities (DANE) TLSA Records Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", draft-ietf-dane-srv-06 (work in with SRV Records", draft-ietf-dane-srv-06 (work in
progress), June 2014. progress), June 2014.
[I-D.ietf-tls-downgrade-scsv] [I-D.ietf-tls-downgrade-scsv]
Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", draft-ietf-tls-downgrade-scsv-02 (work in Attacks", draft-ietf-tls-downgrade-scsv-02 (work in
progress), November 2014. progress), November 2014.
[I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-03 (work in progress), November 2014.
[I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-00 (work in progress), December
2014.
[I-D.ietf-uta-xmpp]
Saint-Andre, P. and a. alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", draft-ietf-uta-xmpp-05 (work in
progress), January 2015.
[Kleinjung2010] [Kleinjung2010]
Kleinjung, T., "Factorization of a 768-Bit RSA Modulus", Kleinjung, T., "Factorization of a 768-Bit RSA Modulus",
CRYPTO 10, 2010, <https://eprint.iacr.org/2010/006.pdf>. CRYPTO 10, 2010, <https://eprint.iacr.org/2010/006.pdf>.
[Krawczyk2001] [Krawczyk2001]
Krawczyk, H., "The order of encryption and authentication Krawczyk, H., "The order of encryption and authentication
for protecting communications (Or: how secure is SSL?)", for protecting communications (Or: how secure is SSL?)",
CRYPTO 01, 2001, <https://eprint.iacr.org/2001/045.pdf>. CRYPTO 01, 2001, <https://eprint.iacr.org/2001/045.pdf>.
[Multiple-Encryption] [Multiple-Encryption]
skipping to change at page 22, line 24 skipping to change at page 23, line 49
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September Algorithm and Its Use with IPsec", RFC 3602, September
2003. 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
August 2011. August 2011.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport
Layer Security (TLS)", RFC 6460, January 2012. Layer Security (TLS)", RFC 6460, January 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
skipping to change at page 26, line 34 skipping to change at page 28, line 8
o Discussion of the regular TLS mandatory cipher suite. o Discussion of the regular TLS mandatory cipher suite.
A.12. draft-sheffer-tls-bcp-00 A.12. draft-sheffer-tls-bcp-00
o Initial version. o Initial version.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Porticor Intuit
29 HaHarash St. 4 HaHarash St.
Hod HaSharon 4501303 Hod HaSharon 4524075
Israel Israel
Email: yaronf.ietf@gmail.com Email: yaronf.ietf@gmail.com
Ralph Holz Ralph Holz
Technische Universitaet Muenchen Technische Universitaet Muenchen
Boltzmannstr. 3 Boltzmannstr. 3
Garching 85748 Garching 85748
Germany Germany
 End of changes. 48 change blocks. 
123 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/