Deprecating FFDH(E) Ciphersuites 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 28 August 2021.¶

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

Table of Contents

1. Introduction

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, 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. (Note that Raccoon only applies to finite field DH cipher suites, and not those based on elliptic curves.) While these side channels can be avoided in implementations, doing is demonstrably difficult given the prevalence of related side channels in TLS implementations.¶

Given these problems, this document updates [RFC4346], [RFC5246], [RFC4162], [RFC6347], [RFC5932], [RFC5288], [RFC6209], [RFC6367], [RFC8422], [RFC5289], and [RFC5469] to deprecate, prohibiting and discouraging, cipher suites with key reuse.¶

2. Non-Ephemeral Diffie Hellman

Clients MUST NOT offer non-ephemeral DH cipher suites in TLS 1.0, 1.1, and 1.2 connections. This includes all cipher suites listed in the following table.¶

Clients SHOULD NOT offer non-ephemeral ECDH cipher suites in TLS 1.0, 1.1, and 1.2 connections. This includes all cipher suites listed in the following table.¶

3. Ephemeral Diffie Hellman

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 secret properties of these connections. In the case of DHE (finite field DH) cipher suites, such reuse may also lead to vulnerabilities such as those use in the [Raccoon] attack. See Section 5 for related discussion.¶

4. IANA Considerations

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

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

Raccoon does not apply to non-ephemeral elliptic curve DH suites, since the same timing side channel does not exist. However, such re-use is still discouraged, and thus deprecated in this document.¶

6. Acknowledgments

This document was inspired by discussion on the TLS WG mailing list and a suggestion by Filippo Valsorda following release of the [Raccoon] attack.¶

Authors' Addresses