draft-ietf-uta-tls-bcp-10.txt   draft-ietf-uta-tls-bcp-11.txt 
UTA Y. Sheffer UTA Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Best Current Practice R. Holz Intended status: Best Current Practice R. Holz
Expires: August 24, 2015 TUM Expires: August 24, 2015 TUM
P. Saint-Andre P. Saint-Andre
&yet &yet
February 20, 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-10 draft-ietf-uta-tls-bcp-11
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 their including attacks on its most commonly used cipher suites and their
modes of operation. This document provides recommendations for modes of operation. This document provides recommendations for
improving the security of deployed services that use TLS and DTLS. improving the security of deployed services that use TLS and DTLS.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . 11 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 Exponential 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 . . . . . . . . . . . . . . . . . . . . 14 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 14
5.2. Unauthenticated TLS and Opportunistic Security . . . . . 15 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 16 7.1. Host Name Validation . . . . . . . . . . . . . . . . . . 16
7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 17 7.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 17
7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 18 7.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 18
7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 18 7.5. Certificate Revocation . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 25 A.1. draft-ietf-uta-tls-bcp-08 . . . . . . . . . . . . . . . . 25
A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 25 A.2. draft-ietf-uta-tls-bcp-07 . . . . . . . . . . . . . . . . 25
A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 25 A.3. draft-ietf-uta-tls-bcp-06 . . . . . . . . . . . . . . . . 25
A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 25 A.4. draft-ietf-uta-tls-bcp-05 . . . . . . . . . . . . . . . . 25
A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 26 A.5. draft-ietf-uta-tls-bcp-04 . . . . . . . . . . . . . . . . 25
A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 26 A.6. draft-ietf-uta-tls-bcp-03 . . . . . . . . . . . . . . . . 25
A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 26 A.7. draft-ietf-uta-tls-bcp-02 . . . . . . . . . . . . . . . . 26
A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 26 A.8. draft-ietf-tls-bcp-01 . . . . . . . . . . . . . . . . . . 26
A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 27 A.9. draft-ietf-tls-bcp-00 . . . . . . . . . . . . . . . . . . 26
A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 27 A.10. draft-sheffer-tls-bcp-02 . . . . . . . . . . . . . . . . 27
A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 27 A.11. draft-sheffer-tls-bcp-01 . . . . . . . . . . . . . . . . 27
A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 27 A.12. draft-sheffer-tls-bcp-00 . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 their modes of operation. For instance, both the AES-CBC suites and their modes of operation. For instance, both the AES-CBC
[RFC3602] and RC4 [RFC7465] encryption algorithms, which together [RFC3602] and RC4 [RFC7465] encryption algorithms, which together
skipping to change at page 10, line 12 skipping to change at page 10, line 12
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 SHOULD NOT negotiate cipher suites based on RSA o Implementations SHOULD NOT negotiate cipher suites based on RSA
key transport, a.k.a. "static RSA". key transport, a.k.a. "static RSA".
Rationale: These cipher suites, which have assigned values Rationale: These cipher suites, which have assigned values
starting with the string "TLS_RSA_WITH_*", have several drawbacks, starting with the string "TLS_RSA_WITH_*", have several drawbacks,
especially the fact that they do not support forward secrecy. especially the fact that they do not support forward secrecy.
o Implementations MUST support and prefer to negotiate, cipher o Implementations MUST support and prefer to negotiate cipher suites
suites offering forward secrecy, such as those in the Ephemeral offering forward secrecy, such as those in the Ephemeral Diffie-
Diffie-Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and
and "ECDHE") families. "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 11, line 51 skipping to change at page 12, line 5
[RFC4492]. In addition, clients SHOULD send an ec_point_formats [RFC4492]. In addition, clients SHOULD send an ec_point_formats
extension with a single element, "uncompressed". extension with a single element, "uncompressed".
4.3. Public Key Length 4.3. Public Key Length
When using the cipher suites recommended in this document, two public When using the cipher suites recommended in this document, two public
keys are normally used in the TLS handshake: one for the Diffie- keys are normally used in the TLS handshake: one for the Diffie-
Hellman key agreement and one for server authentication. Where a Hellman key agreement and one for server authentication. Where a
client certificate is used, a third public key is added. client certificate is used, a third public key is added.
With a key exchange based on modular Diffie-Hellman ("DHE" cipher With a key exchange based on modular exponential (modp) Diffie-
suites), DH key lengths of at least 2048 bits are RECOMMENDED. Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048
bits are RECOMMENDED.
Rationale: For various reasons, in practice DH keys are typically Rationale: For various reasons, in practice DH keys are typically
generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, generated in lengths that are powers of two (e.g., 2^10 = 1024 bits,
2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits
would be roughly equivalent to only an 80-bit symmetric key would be roughly equivalent to only an 80-bit symmetric key
[RFC3766], it is better to use keys longer than that for the "DHE" [RFC3766], it is better to use keys longer than that for the "DHE"
family of cipher suites. A DH key of 1926 bits would be roughly family of cipher suites. A DH key of 1926 bits would be roughly
equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048
bits might be sufficient for at least the next 10 years bits might be sufficient for at least the next 10 years
[NIST.SP.800-56A]. See Section 4.4 for additional information on the [NIST.SP.800-56A]. See Section 4.4 for additional information on the
use of modular Diffie-Hellman in TLS. use of modp Diffie-Hellman in TLS.
As noted in [RFC3766], correcting for the emergence of a TWIRL As noted in [RFC3766], correcting for the emergence of a TWIRL
machine would imply that 1024-bit DH keys yield about 65 bits of machine would imply that 1024-bit DH keys yield about 65 bits of
equivalent strength and that a 2048-bit DH key would yield about 92 equivalent strength and that a 2048-bit DH key would yield about 92
bits of equivalent strength. bits of equivalent strength.
With regard to ECDH keys, the IANA named curve registry contains With regard to ECDH keys, the IANA named curve registry contains
160-bit elliptic curves which are considered to be roughly equivalent 160-bit elliptic curves which are considered to be roughly equivalent
to only an 80-bit symmetric key [ECRYPT-II]. Curves of less than to only an 80-bit symmetric key [ECRYPT-II]. Curves of less than
192-bits SHOULD NOT be used. 192-bits SHOULD NOT be used.
When using RSA servers SHOULD authenticate using certificates with at When using RSA servers SHOULD authenticate using certificates with at
least a 2048-bit modulus for the public key. In addition, the use of least a 2048-bit modulus for the public key. In addition, the use of
the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for
more details). Clients SHOULD indicate to servers that they request more details). Clients SHOULD indicate to servers that they request
SHA-256, by using the "Signature Algorithms" extension defined in SHA-256, by using the "Signature Algorithms" extension defined in
TLS 1.2. TLS 1.2.
4.4. Modular vs. Elliptic Curve DH Cipher Suites 4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites
Not all TLS implementations support both modular and elliptic curve Not all TLS implementations support both modular exponential (modp)
Diffie-Hellman groups, as required by Section 4.2. Some and elliptic curve (EC) Diffie-Hellman groups, as required by
implementations are severely limited in the length of DH values. Section 4.2. Some implementations are severely limited in the length
When such implementations need to be accommodated, the following are of DH values. When such implementations need to be accommodated, the
RECOMMENDED (in priority order): following are RECOMMENDED (in priority order):
1. Elliptic Curve DHE with appropriately negotiated parameters 1. Elliptic Curve DHE with appropriately negotiated parameters
(e.g., the curve to be used) and a MAC algorithm stronger than (e.g., the curve to be used) and a MAC algorithm stronger than
HMAC-SHA1 [RFC5289] 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
the most part, have now been resolved [RFC6090]). Note that ECDHE the most part, have now been resolved [RFC6090]). Note that ECDHE
cipher suites exist for both RSA and ECDSA certificates so moving to cipher suites exist for both RSA and ECDSA certificates so moving to
ECDHE cipher suites does not require moving away from RSA based ECDHE cipher suites does not require moving away from RSA based
certificates. On the other hand, there are two related issues certificates. On the other hand, there are two related issues
hindering effective use of modular Diffie-Hellman cipher suites in hindering effective use of modp Diffie-Hellman cipher suites in TLS:
TLS:
o There are no standardized, widely implemented protocol mechanisms o There are no standardized, widely implemented protocol mechanisms
to negotiate the DH groups or parameter lengths supported by to negotiate the DH groups or parameter lengths supported by
client and server. client and server.
o Many servers choose DH parameters of 1024 bits or fewer. o Many servers choose DH parameters of 1024 bits or fewer.
o There are widely deployed client implementations that reject o There are widely deployed client implementations that reject
received DH parameters if they are longer than 1024 bits. In received DH parameters if they are longer than 1024 bits. In
addition, several implementations do not perform appropriate addition, several implementations do not perform appropriate
validation of group parameters and are vulnerable to attacks validation of group parameters and are vulnerable to attacks
referenced in Section 2.9 of [RFC7457] referenced in Section 2.9 of [RFC7457]
Note that with DHE and ECDHE cipher suites, the TLS master key only Note that with DHE and ECDHE cipher suites, the TLS master key only
depends on the Diffie-Hellman parameters and not on the strength of depends on the Diffie-Hellman parameters and not on the strength of
the RSA certificate; moreover, 1024 bit modular DH parameters are the RSA certificate; moreover, 1024 bit modp DH parameters are
generally considered insufficient at this time. generally considered insufficient at this time.
With modular ephemeral DH, deployers ought to carefully evaluate With modp ephemeral DH, deployers ought to carefully evaluate
interoperability vs. security considerations when configuring their interoperability vs. security considerations when configuring their
TLS endpoints. TLS endpoints.
4.5. Truncated HMAC 4.5. Truncated HMAC
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
skipping to change at page 14, line 46 skipping to change at page 14, line 49
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.
o Data integrity: any changes made to the communication in transit o Data integrity: any changes made to the communication in transit
are detectable by the receiver. are detectable by the receiver.
o Authentication: an end-point of the TLS communication is o Authentication: an end-point of the TLS communication is
authenticated as the intended entity to communicate with. authenticated as the intended entity to communicate with.
With regard to authentication, TLS enables authentication of one or With regard to authentication, TLS enables authentication of one or
both end-points in the communication. Although some TLS usage both end-points in the communication. In the context of
scenarios do not require authentication, those scenarios are not in opportunistic security [RFC7435], TLS is sometimes used without
scope for this document (a rationale for this decision is provided authentication. As discussed in Section 5.2, considerations for
under Section 5.2). opportunistic security are not in scope for this document.
If deployers deviate from the recommendations given in this document, If deployers deviate from the recommendations given in this document,
they need to be aware that they might lose access to one of the they need to be aware that they might lose access to one of the
foregoing security services. foregoing security services.
This document applies only to environments where confidentiality is This document applies only to environments where confidentiality is
required. It recommends algorithms and configuration options that required. It recommends algorithms and configuration options that
enforce secrecy of the data-in-transit. enforce secrecy of the data-in-transit.
This document also assumes that data integrity protection is always This document also assumes that data integrity protection is always
skipping to change at page 15, line 34 skipping to change at page 15, line 34
clients are user agents like Web browsers or email software. clients are user agents like Web browsers or email software.
This document does not address the rarer deployment scenarios where This document does not address the rarer deployment scenarios where
one of the above three properties is not desired, such as the use one of the above three properties is not desired, such as the use
case described under Section 5.2 below. As another scenario where case described under Section 5.2 below. As another scenario where
confidentiality is not needed, consider a monitored network where the confidentiality is not needed, consider a monitored network where the
authorities in charge of the respective traffic domain require full authorities in charge of the respective traffic domain require full
access to unencrypted (plaintext) traffic, and where users access to unencrypted (plaintext) traffic, and where users
collaborate and send their traffic in the clear. collaborate and send their traffic in the clear.
5.2. Unauthenticated TLS and Opportunistic Security 5.2. Opportunistic Security
Several important applications use TLS to protect data between a TLS
client and a TLS server, but do so without the TLS client necessarily
verifying the server's certificate. This practice is often called
"unauthenticated TLS". The reader is referred to
[I-D.ietf-dane-smtp-with-dane] for an example and an explanation of
why this less secure practice will likely remain common in the
context of SMTP (especially for MTA-to-MTA communications). The
practice is also encountered in similar contexts such as server-to-
server traffic on the XMPP network (where multi-tenant hosting
environments make it difficult for operators to obtain proper
certificates for all of the domains they service).
Furthermore, in some scenarios the use of TLS itself is optional, There are several important scenarios in which the use of TLS is
i.e. the client decides dynamically ("opportunistically") whether to optional, i.e., the client decides dynamically ("opportunistically")
use TLS with a particular server or to connect in the clear. This whether to use TLS with a particular server or to connect in the
practice, often called "opportunistic security", is described at clear. This practice, often called "opportunistic security", is
length in [RFC7435]. described at length in [RFC7435] and is often motivated by a desire
for backward compatibility with legacy deployments.
It can be argued that the recommendations provided in this document In these scenarios, some of the recommendations in this document
ought to apply equally to unauthenticated TLS as well as might be too strict, since adhering to them could cause fallback to
authenticated TLS. That would keep TLS implementations and cleartext, a worse outcome than using TLS with an outdated protocol
deployments in sync, which is a desirable property given that servers version or cipher suite.
can be used simultaneously for unauthenticated TLS and for
authenticated TLS (indeed, a server cannot know whether a client
might attempt authenticated or unauthenticated TLS). On the other
hand, it has been argued that some of the recommendations in this
document might be too strict for unauthenticated scenarios and that
any security is better than no security at all (i.e., sending traffic
in the clear), even if it means deploying outdated protocol versions
and ciphers in unauthenticated scenarios. The sense of the UTA
Working Group was to complete work on this document about
authenticated TLS and to initiate work on a separate document about
unauthenticated TLS.
In summary: this document does not apply to unauthenticated TLS use This document specifies best practices for TLS in general. A
cases. separate document containing recommendations for the use of TLS with
opportunistic security is to be completed in the future.
6. IANA Considerations 6. IANA Considerations
This document requests no actions of IANA. [Note to RFC Editor: This document requests no actions of IANA. [Note to RFC Editor:
please remove this whole section before publication.] please remove this whole section before publication.]
7. Security Considerations 7. Security Considerations
This entire document discusses the security practices directly This entire document discusses the security practices directly
affecting applications using the TLS protocol. This section contains affecting applications using the TLS protocol. This section contains
 End of changes. 21 change blocks. 
65 lines changed or deleted 44 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/