| < 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||