--- 1/draft-ietf-uta-rfc7525bis-02.txt 2021-10-25 05:13:46.302117322 -0700 +++ 2/draft-ietf-uta-rfc7525bis-03.txt 2021-10-25 05:13:46.370119023 -0700 @@ -1,24 +1,24 @@ UTA Working Group Y. Sheffer Internet-Draft Intuit Obsoletes: 7525 (if approved) R. Holz Updates: 5288, 6066 (if approved) University of Twente Intended status: Best Current Practice P. Saint-Andre -Expires: 1 March 2022 Mozilla +Expires: 28 April 2022 Mozilla T. Fossati arm - 28 August 2021 + 25 October 2021 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) - draft-ietf-uta-rfc7525bis-02 + draft-ietf-uta-rfc7525bis-03 Abstract Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. @@ -37,21 +37,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 1 March 2022. + This Internet-Draft will expire on 28 April 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -66,53 +66,54 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. General Recommendations . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9 - 3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 10 + 3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 9 3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10 3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11 - 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 12 + 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 11 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13 - 4.2.1. Implementation Details . . . . . . . . . . . . . . . 14 + 4.2.1. Implementation Details . . . . . . . . . . . . . . . 13 4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14 - 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15 + 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 14 4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15 4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18 6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21 6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32 Appendix B. Document History . . . . . . . . . . . . . . . . . . 33 - B.1. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33 - B.2. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33 - B.3. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34 - B.4. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34 - B.5. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34 + B.1. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 33 + B.2. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33 + B.3. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33 + B.4. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34 + B.5. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34 + B.6. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Transport Layer Security (TLS) [RFC5246] and Datagram Transport Security Layer (DTLS) [RFC6347] are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the years leading to 2015, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. For instance, both @@ -403,31 +404,24 @@ server is able to track the client, in some cases indefinitely. See [Sy2018] for more details. 3.5. TLS Renegotiation Where handshake renegotiation is implemented, both clients and servers MUST implement the renegotiation_info extension, as defined in [RFC5746]. Note: this recommendation applies to TLS 1.2 only, because renegotiation has been removed from TLS 1.3. - The most secure option for countering the Triple Handshake attack is - to refuse any change of certificates during renegotiation. In - addition, TLS clients SHOULD apply the same validation policy for all - certificates received over a connection. The [triple-handshake] - document suggests several other possible countermeasures, such as - binding the master secret to the full handshake (see [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. + A related attack resulting from TLS session parameters not properly + authenticated is Triple Handshake [triple-handshake]. To address + this attack, TLS 1.2 implementations SHOULD support the + extended_master_secret extension defined in [RFC7627]. 3.6. Post-Handshake Authentication Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post- handshake authentication and key update mechanisms. In the context of protocols that multiplex requests over a single connection (such as HTTP/2), post-handshake authentication has the same problems as TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the advice provided for HTTP/2 in [RFC8740]. @@ -443,46 +437,45 @@ Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single address, and therefore enables fine-grained security for these virtual servers, by allowing each one to have its own certificate. However, SNI also leaks the target domain for a given connection; this information leak will be plugged by use of TLS Encrypted Client Hello. In order to prevent the attacks described in [ALPACA], a server that does not recognize the presented server name SHOULD NOT continue the - handshake and instead fail with a fatal-level - "unrecognized_name(112)" alert. Note that this recommendation - updates Section 3 of [RFC6066]: "If the server understood the - ClientHello extension but does not recognize the server name, the - server SHOULD take one of two actions: either abort the handshake by - sending a fatal-level "unrecognized_name(112)" alert or continue the - handshake." It is also RECOMMENDED that clients abort the handshake - if the server acknowledges the SNI hostname with a different hostname - than the one sent by the client. + handshake and instead fail with a fatal-level unrecognized_name(112) + alert. Note that this recommendation updates Section 3 of [RFC6066]: + "If the server understood the ClientHello extension but does not + recognize the server name, the server SHOULD take one of two actions: + either abort the handshake by sending a fatal-level + unrecognized_name(112) alert or continue the handshake." It is also + RECOMMENDED that clients abort the handshake if the server + acknowledges the SNI hostname with a different hostname than the one + sent by the client. 3.8. Application-Layer Protocol Negotiation TLS implementations (both client- and server-side) MUST support the Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. In order to prevent "cross-protocol" attacks resulting from failure to ensure that a message intended for use in one protocol cannot be mistaken for a message for use in another protocol, servers should strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: "In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal - "no_application_protocol" alert." It is also RECOMMENDED that - clients abort the handshake if the server acknowledges the ALPN - extension, but does not select a protocol from the client list. - Failure to do so can result in attacks such those described in - [ALPACA]. + no_application_protocol alert." It is also RECOMMENDED that clients + abort the handshake if the server acknowledges the ALPN extension, + but does not select a protocol from the client list. Failure to do + so can result in attacks such those described in [ALPACA]. Protocol developers are strongly encouraged to register an ALPN identifier for their protocols. This applies to new protocols, as well as well-established protocols such as SMTP. 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 The 0-RTT early data feature is new in TLS 1.3. It provides improved latency when TLS connections are resumed, at the potential cost of security. As a result, it requires special attention from @@ -652,37 +645,55 @@ 4.3. Cipher Suites for TLS 1.3 This document does not specify any cipher suites for TLS 1.3. Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite recommendations. 4.4. Limits on Key Usage All ciphers have an upper limit on the amount of traffic that can be - securely encrypted with any given key. In the case of AEAD cipher - suites, the limit is typically determined by the cipher's integrity - guarantees. When the amount of traffic for a particular connection - has reached the limit, an implementation SHOULD perform a new - handshake (or in TLS 1.3, a Key Update) to rotate the session key. + securely protected with any given key. In the case of AEAD cipher + suites, two separate limits are maintained for each key: - For all AES-GCM cipher suites recommended for TLS 1.2 in this - document, the limit for one connection is 2^24.5 full-size records - (about 24 million). This is the same number as for TLS 1.3 with the - equivalent cipher suites. + 1. Confidentiality limit (CL), i.e., the number of records that can + be encrypted. - // TODO: refer to {{I-D.irtf-cfrg-aead-limits}} once it has added the - // derivation for TLS 1.2, which is different from TLS 1.3. - // Different derivation, same numbers. + 2. Integrity limit (IL), i.e., the number of records that are + allowed to fail authentication. + + The latter only applies to DTLS since TLS connections are torn down + on the first decryption failure. + + When a sender is approaching CL, the implementation SHOULD initiate a + new handshake (or in TLS 1.3, a Key Update) to rotate the session + key. + + When a receiver has reached IL, the implementation SHOULD close the + connection. For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of - [RFC8446]. + [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher + suites, readers are referred to Section 4.5.3 of + [I-D.ietf-tls-dtls13]. + + For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in + this document, CL can be derived by plugging the corresponding + parameters into the inequalities in Section 6.1 of + [I-D.irtf-cfrg-aead-limits] that apply to random, partially implicit + nonces, i.e., the nonce construction used in TLS 1.2. Although the + obtained figures are slightly higher than those for TLS 1.3, it is + RECOMMENDED that the same limit of 2^24.5 records is used for both + versions. + + For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained + from the same inequalities referenced above) is 2^28. 4.5. Public Key Length When using the cipher suites recommended in this document, two public keys are normally used in the TLS handshake: one for the Diffie- Hellman key agreement and one for server authentication. Where a client certificate is used, a third public key is added. With a key exchange based on modular exponential (MODP) Diffie- Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 @@ -883,22 +894,22 @@ attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE- 2016-10213, CVE-2016-10212, CVE-2017-5933.) While this problem has been fixed in TLS 1.3, which enforces a deterministic method to generate nonces from record sequence numbers and shared secrets for all of its AEAD cipher suites (including AES- GCM), TLS 1.2 implementations could still choose their own (potentially insecure) nonce generation methods. It is therefore RECOMMENDED that TLS 1.2 implementations use the - 64-bit sequence number to populate the "nonce_explicit" part of the - GCM nonce, as described in the first two paragraphs of Section 5.3 of + 64-bit sequence number to populate the nonce_explicit part of the GCM + nonce, as described in the first two paragraphs of Section 5.3 of [RFC8446]. Note that this recommendation updates Section 3 of [RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number." We note that at the time of writing there are no cipher suites defined for nonce reuse resistant algorithms such as AES-GCM-SIV [RFC8452]. 6.3. Forward Secrecy Forward secrecy (also called "perfect forward secrecy" or "PFS" and @@ -1070,23 +1081,23 @@ and Orit Levin as the working group chairs and Pete Resnick as the sponsoring Area Director. 8. References 8.1. Normative References [I-D.ietf-httpbis-semantics] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- - httpbis-semantics-18, 18 August 2021, + httpbis-semantics-19, 12 September 2021, . + semantics-19.txt>. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-43, 30 April 2021, . [I-D.ietf-tls-oldversions-deprecate] @@ -1158,20 +1169,26 @@ [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, . [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, . + [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., + Langley, A., and M. Ray, "Transport Layer Security (TLS) + Session Hash and Extended Master Secret Extension", + RFC 7627, DOI 10.17487/RFC7627, September 2015, + . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, DOI 10.17487/RFC8740, February 2020, @@ -1415,27 +1432,20 @@ . [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . - [SESSION-HASH] - Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., - Langley, A., and M. Ray, "Transport Layer Security (TLS) - Session Hash and Extended Master Secret Extension", - RFC 7627, DOI 10.17487/RFC7627, September 2015, - . - [Smith2013] Smith, B., "Proposal to Change the Default TLS Ciphersuites Offered by Browsers.", 2013, . [Soghoian2011] Soghoian, C. and S. Stamm, "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL", SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010, . @@ -1473,61 +1483,72 @@ - Added TLS 1.3 at a SHOULD level. - Similar changes to DTLS, pending publication of DTLS 1.3. - Specific guidance for multiplexed protocols. - MUST-level implementation requirement for ALPN, and more specific SHOULD-level guidance for ALPN and SNI. + - Limits on key usage. + - New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce- - Disrespecting Adversaries" + Disrespecting Adversaries". * Differences specific to TLS 1.2: - Fallback SCSV as a MUST for TLS 1.2. - - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. + - SHOULD-level guidance on AES-GCM nonce generation. - SHOULD NOT use static DH keys or reuse ephemeral DH keys across multiple connections. - 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192 previously. + - Support for extended_master_secret is a SHOULD. Also removed + other, more complicated, related mitigations. + * Differences specific to TLS 1.3: - New TLS 1.3 capabilities: 0-RTT. - Removed capabilities: renegotiation, compression. - Added mention of TLS Encrypted Client Hello, but no recommendation to use until it is finalized. - SHOULD-level requirement for forward secrecy in TLS 1.3 session resumption. - Generic SHOULD-level guidance to avoid 0-RTT unless it is documented for the particular protocol. Appendix B. Document History // Note to RFC Editor: please remove before publication. -B.1. draft-ietf-uta-rfc7525bis-02 +B.1. draft-ietf-uta-rfc7525bis-03 + + * Cipher integrity and confidentiality limits. + + * Require extended_master_secret. + +B.2. draft-ietf-uta-rfc7525bis-02 * Adjusted text about ALPN support in application protocols * Incorporated text from draft-ietf-tls-md5-sha1-deprecate -B.2. draft-ietf-uta-rfc7525bis-01 +B.3. draft-ietf-uta-rfc7525bis-01 * Many more changes, including: - SHOULD-level requirement for forward secrecy in TLS 1.3 session resumption. - Removed TLS 1.2 capabilities: renegotiation, compression. - Specific guidance for multiplexed protocols. @@ -1538,39 +1559,39 @@ documented for the particular protocol. - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. - SHOULD NOT use static DH keys or reuse ephemeral DH keys across multiple connections. - 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from 192. -B.3. draft-ietf-uta-rfc7525bis-00 +B.4. draft-ietf-uta-rfc7525bis-00 * Renamed: WG document. * Started populating list of changes from RFC 7525. * General rewording of abstract and intro for revised version. * Protocol versions, fallback. * Reference to ECHO. -B.4. draft-sheffer-uta-rfc7525bis-00 +B.5. draft-sheffer-uta-rfc7525bis-00 * Renamed, since the BCP number does not change. * Added an empty "Differences from RFC 7525" section. -B.5. draft-sheffer-uta-bcp195bis-00 +B.6. draft-sheffer-uta-bcp195bis-00 * Initial release, the RFC 7525 text as-is, with some minor editorial changes to the references. Authors' Addresses Yaron Sheffer Intuit Email: yaronf.ietf@gmail.com