Internet-Draft | Deprecating FFDH | July 2021 |
Bartle, et al. | Expires 31 January 2022 | [Page] |
This document deprecates the use of finite field Diffie Hellman cipher suites and discourages the use of elliptic curve Diffie Hellman cipher suites, both of which have known vulnerabilities or improper security properties when implemented incorrectly.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/.¶
Source for this draft and an issue tracker can be found at https://github.com/cbartle891/draft-deprecate-ffdhe.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 31 January 2022.¶
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 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
TLS supports a variety of key exchange algorithms, including those based on finite field and elliptic curve Diffie Hellman (DH) groups. Each of these also come in ephemeral and non-ephemeral varieties. Non-ephemeral DH algorithms use static DH public keys included in the authenticating peer's certificate; see [RFC4492] for discussion. In contrast, ephemeral DH algorithms use ephemeral DH public keys sent in the handshake and authenticated by the peer's certificate. Ephemeral and non-ephemeral finite field DH algorithms are called DHE and DH, respectively, and ephemeral and non-ephemeral elliptic curve DH algorithms are called ECDHE and ECDH, respectively [RFC4492].¶
In general, non-ephemeral cipher suites are not recommended due to their lack of forward secrecy. However, as demonstrated by the [Raccoon] attack on finite-field DH, public key reuse, either via non-ephemeral cipher suites or reused keys with ephemeral cipher suites, can lead to timing side channels that may leak connection secrets. For elliptic curve DH, invalid curve attacks broadly follow the same pattern, where a long-lived secret is extracted using side channels [ICA], further demonstrating the security risk of reusing public keys. While both side channels can be avoided in implementations, experience shows that in practice, implementations may fail to thwart such attacks due to the complexity of the required mitigations.¶
Given these problems, this document updates [RFC4346], [RFC5246], [RFC4162], [RFC6347], [RFC5932], [RFC5288], [RFC6209], [RFC6367], [RFC8422], [RFC5289], and [RFC5469] to deprecate cipher suites with key reuse, prohibiting and discouraging their use.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Clients MUST NOT offer non-ephemeral DH cipher suites in TLS 1.2 connections. (Note that TLS 1.0 and 1.1 are deprecated by [RFC8996].) This includes all cipher suites listed in the following table.¶
Ciphersuite | Reference |
---|---|
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA | [RFC4346] |
TLS_DH_DSS_WITH_DES_CBC_SHA | [RFC5469] |
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA | [RFC5246] |
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA | [RFC4346] |
TLS_DH_RSA_WITH_DES_CBC_SHA | [RFC5469] |
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA | [RFC5246] |
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 | [RFC4346][RFC6347] |
TLS_DH_anon_WITH_RC4_128_MD5 | [RFC5246][RFC6347] |
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA | [RFC4346] |
TLS_DH_anon_WITH_DES_CBC_SHA | [RFC5469] |
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA | [RFC5246] |
TLS_DH_DSS_WITH_AES_128_CBC_SHA | [RFC5246] |
TLS_DH_RSA_WITH_AES_128_CBC_SHA | [RFC5246] |
TLS_DH_anon_WITH_AES_128_CBC_SHA | [RFC5246] |
TLS_DH_DSS_WITH_AES_256_CBC_SHA | [RFC5246] |
TLS_DH_RSA_WITH_AES_256_CBC_SHA | [RFC5246] |
TLS_DH_anon_WITH_AES_256_CBC_SHA | [RFC5246] |
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 | [RFC5246] |
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 | [RFC5246] |
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA | [RFC5932] |
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA | [RFC5932] |
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA | [RFC5932] |
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 | [RFC5246] |
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 | [RFC5246] |
TLS_DH_anon_WITH_AES_128_CBC_SHA256 | [RFC5246] |
TLS_DH_anon_WITH_AES_256_CBC_SHA256 | [RFC5246] |
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA | [RFC5932] |
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA | [RFC5932] |
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA | [RFC5932] |
TLS_DH_DSS_WITH_SEED_CBC_SHA | [RFC4162] |
TLS_DH_RSA_WITH_SEED_CBC_SHA | [RFC4162] |
TLS_DH_anon_WITH_SEED_CBC_SHA | [RFC4162] |
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 | [RFC5288] |
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 | [RFC5288] |
TLS_DH_DSS_WITH_AES_128_GCM_SHA256 | [RFC5288] |
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 | [RFC5288] |
TLS_DH_anon_WITH_AES_128_GCM_SHA256 | [RFC5288] |
TLS_DH_anon_WITH_AES_256_GCM_SHA384 | [RFC5288] |
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 | [RFC5932] |
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 | [RFC5932] |
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 | [RFC5932] |
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 | [RFC5932] |
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 | [RFC5932] |
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 | [RFC5932] |
TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256 | [RFC6209] |
TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384 | [RFC6209] |
TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256 | [RFC6209] |
TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384 | [RFC6209] |
TLS_DH_anon_WITH_ARIA_128_CBC_SHA256 | [RFC6209] |
TLS_DH_anon_WITH_ARIA_256_CBC_SHA384 | [RFC6209] |
TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256 | [RFC6209] |
TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384 | [RFC6209] |
TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256 | [RFC6209] |
TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384 | [RFC6209] |
TLS_DH_anon_WITH_ARIA_128_GCM_SHA256 | [RFC6209] |
TLS_DH_anon_WITH_ARIA_256_GCM_SHA384 | [RFC6209] |
TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367] |
TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367] |
TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367] |
TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367] |
TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367] |
TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367] |
Clients SHOULD NOT offer non-ephemeral ECDH cipher suites in TLS 1.2 connections. (Note that TLS 1.0 and 1.1 are deprecated by [RFC8996].) This includes all cipher suites listed in the following table.¶
Ciphersuite | Reference |
---|---|
TLS_ECDH_ECDSA_WITH_NULL_SHA | [RFC8422] |
TLS_ECDH_ECDSA_WITH_RC4_128_SHA | [RFC8422][RFC6347] |
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA | [RFC8422] |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA | [RFC8422] |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA | [RFC8422] |
TLS_ECDH_RSA_WITH_NULL_SHA | [RFC8422] |
TLS_ECDH_RSA_WITH_RC4_128_SHA | [RFC8422][RFC6347] |
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA | [RFC8422] |
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA | [RFC8422] |
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA | [RFC8422] |
TLS_ECDH_anon_WITH_NULL_SHA | [RFC8422] |
TLS_ECDH_anon_WITH_RC4_128_SHA | [RFC8422][RFC6347] |
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | [RFC8422] |
TLS_ECDH_anon_WITH_AES_128_CBC_SHA | [RFC8422] |
TLS_ECDH_anon_WITH_AES_256_CBC_SHA | [RFC8422] |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 | [RFC5289] |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 | [RFC5289] |
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 | [RFC5289] |
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 | [RFC5289] |
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 | [RFC5289] |
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 | [RFC5289] |
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 | [RFC5289] |
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 | [RFC5289] |
TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256 | [RFC6209] |
TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384 | [RFC6209] |
TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256 | [RFC6209] |
TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384 | [RFC6209] |
TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256 | [RFC6209] |
TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384 | [RFC6209] |
TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256 | [RFC6209] |
TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384 | [RFC6209] |
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 | [RFC6367] |
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 | [RFC6367] |
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256 | [RFC6367] |
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384 | [RFC6367] |
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367] |
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367] |
TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367] |
TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367] |
Clients and servers MUST NOT reuse ephemeral DHE or ECDHE public keys across TLS connections for all existing (and future) TLS versions. Doing so invalidates forward secrecy properties of these connections. In the case of DHE (finite field DH) cipher suites, such reuse may also lead to vulnerabilities such as those used in the [Raccoon] attack. See Section 5 for related discussion.¶
This document makes no requests to IANA. All cipher suites listed in Section 2 are already marked as not recommended in the "TLS Cipher Suites" registry.¶
Non-ephemeral finite field DH cipher suites (TLS_DH_*), as well as ephemeral key reuse for finite field DH cipher suites, are prohibited due to the [Raccoon] attack. Both are already considered bad practice since they do not provide forward secrecy. However, Raccoon revealed that timing side channels in processing TLS premaster secrets may be exploited to reveal the encrypted premaster secret.¶
For non-ephemeral elliptic curve DH cipher suites, invalid curve attacks similarly exploit side channels to extract the secret from a long-lived public key. These attacks have been shown to be practical against real-world TLS implementations [ICA]. Therefore, this document discourages the reuse of elliptic curve DH public keys.¶
This document was inspired by discussion on the TLS WG mailing list and a suggestion by Filippo Valsorda following the release of the [Raccoon] attack. Thanks to Christopher A. Wood for writing up the initial draft of this document.¶