Deprecating Obsolete Key Exchange Methods in TLS

Status of This Memo

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 16 December 2022.¶

Copyright Notice

Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

TLS supports a variety of key exchange algorithms, including RSA, Diffie Hellman over a finite field, and elliptic curve Diffie Hellman (ECDH).¶

Diffie Hellman key exchange, over any group, comes 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 (or FFDHE and FFDH), 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 similarly exploit secret reuse in order to break security [ICA], further demonstrating the 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 and number of the required mitigations.¶

Additionally, RSA key exchange suffers from security problems that are independent of implementation choices as well as problems that stem purely from the difficulty of implementing security countermeasures correctly.¶

At a rough glance, the problems affecting FFDHE are as follows:¶

1. FFDHE suffers from interoperability problems because there is no mechanism for negotiating the group size, and some implementations only support small group sizes (see [RFC7919], Section 1).¶
2. In practice, some operators use 1024-bit FFDHE groups since this is the maximum size that ensures wide support (see [RFC7919], Section 1). This size leaves only a small security margin vs. the current discrete log record, which stands at 795 bits [DLOG795].¶
3. Expanding on the previous point, just a handful of very large computations allow an attacker to cheaply decrypt a relatively large fraction of FFDHE traffic (namely, traffic encrypted using particular standardized groups) [weak-dh].¶
4. When secrets are not fully ephemeral, FFDHE suffers from the [Raccoon] side channel attack. (Note that FFDH is inherently vulnerable to the Raccoon attack unless constant-time mitigations are employed.)¶
5. FFDHE groups may have small subgroups, which enables several attacks [subgroups].¶

The problems affecting RSA key exchange are as follows:¶

1. RSA key exchange offers no forward secrecy, by construction.¶
2. RSA key exchange may be vulnerable to Bleichenbacher's attack [BLEI]. Experience shows that variants of this attack arise every few years because implementing the relevant countermeasure correctly is difficult (see [ROBOT], [NEW-BLEI], [DROWN]).¶
3. In addition to the above point, there is no convenient mechanism in TLS for the domain separation of keys. Therefore, a single endpoint that is vulnerable to Bleichenbacher's attack would affect all endpoints sharing the same RSA key (see [XPROT], [DROWN]).¶

Given these problems, this document updates [RFC4346], [RFC5246], [RFC4162], [RFC6347], [RFC5932], [RFC5288], [RFC6209], [RFC6367], [RFC8422], [RFC5289], and [RFC5469] to remediate the above problems.¶

2. Non-Ephemeral Diffie Hellman

Clients MUST NOT offer non-ephemeral FFDH cipher suites in TLS 1.2 connections. (Note that TLS 1.0 and 1.1 are deprecated by [RFC8996] and TLS 1.3 does not support FFDH [RFC8446].) This includes all cipher suites listed in the table in Appendix A.¶

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] and TLS 1.3 does not support ECDH [RFC8446].) This includes all cipher suites listed in the table in Appendix B.¶

3. Ephemeral Finite Field Diffie Hellman

Clients and servers MAY offer fully ephemeral FFDHE cipher suites in TLS 1.2 connections under the following conditions:¶

1. Clients and servers MUST NOT reuse ephemeral DHE public keys across TLS connections for all existing (and future) TLS versions. Doing so invalidates forward secrecy properties of these connections. For DHE, such reuse may also lead to vulnerabilities such as those used in the [Raccoon] attack. See Section 6 for related discussion.¶
2. The group is one of the following well-known groups described in [RFC7919]: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192.¶

(Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]. TLS 1.3 satisfies the second point above [RFC8446] and is not vulnerable to the [Raccoon] Attack.)¶

We note that, previously, supporting the broadest range of clients would have required supporting either RSA key exchange or 1024-bit FFDHE. This is no longer the case, and it is possible to support most clients released since circa 2015 using 2048-bit FFDHE or more modern key exchange methods, and without RSA key exchange [server_side_tls].¶

All the cipher suites that do not meet the above requirements are listed in the table in Appendix C.¶

4. RSA

Clients and servers MUST NOT offer RSA cipher suites in TLS 1.2 connections. (Note that TLS 1.0 and 1.1 are deprecated by [RFC8996], and TLS 1.3 does not support static RSA [RFC8446].) This includes all cipher suites listed in the table in Appendix D. Note that these cipher suites are already marked as not recommended in the "TLS Cipher Suites" registry.¶

5. IANA Considerations

This document makes no requests to IANA. Note that all cipher suites listed in Section 4 and in Section 2 are already marked as not recommended in the "TLS Cipher Suites" registry.¶

6. Security Considerations

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.¶

As for non-ephemeral elliptic curve DH cipher suites, forgoing forward secrecy not only allows retroactive decryption in the event of key compromise but may also enable a broad category of attacks where the attacker exploits key reuse to repeatedly query a cryptographic secret.¶

This category includes, but is not necessarily limited to, the following examples:¶

1. Invalid curve attacks, where the attacker exploits key reuse to repeatedly query and eventually learn the key itself. These attacks have been shown to be practical against real-world TLS implementations [ICA].¶
2. Side channel attacks, where the attacker exploits key reuse and an additional side channel to learn a cryptographic secret. As one example of such attacks, refer to [MAY4].¶
3. Fault attacks, where the attacker exploits key reuse and incorrect calculations to learn a cryptographic secret. As one example of such attacks, see [PARIS256].¶

Such attacks are often implementation-dependent, including the above examples. However, these examples demonstrate that building a system that reuses keys and avoids this category of attacks is difficult in practice. In contrast, avoiding key reuse not only prevents decryption in the event of key compromise, but also precludes this category of attacks altogether. Therefore, this document discourages the reuse of elliptic curve DH public keys.¶

7. Acknowledgments

This document was inspired by discussions 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.¶

Appendix A. DH Cipher Suites Deprecated by This Document

Appendix B. ECDH Cipher Suites Whose Use Is Discouraged by This Document

Appendix C. DHE Cipher Suites Refered to by This Document

Appendix D. RSA Cipher Suites Deprecated by This Document

Authors' Addresses