Deprecating FFDH(E) Ciphersuites in TLS

Document Type Active Internet-Draft (individual)
Authors Carrick  , Nimrod Aviram  , Filippo Valsorda 
Last updated 2021-02-24
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          C. Bartle
Internet-Draft                                               Apple, Inc.
Intended status: Standards Track                               N. Aviram
Expires: 28 August 2021                                                 
                                                             F. Valsorda
                                                        24 February 2021

                Deprecating FFDH(E) Ciphersuites in TLS


   This document deprecates and discourages use of finite field and
   elliptic curve Diffie Hellman cipher suites that have known
   vulnerabilities or improper security properties when implemented

Discussion Venues

   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 (, which is archived

   Source for this draft and an issue tracker can be found at

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

   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 (
   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
     1.1.  Requirements
   2.  Non-Ephemeral Diffie Hellman
   3.  Ephemeral Diffie Hellman
   4.  IANA Considerations
   5.  Security Considerations
   6.  Acknowledgments
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Authors' Addresses

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.

1.1.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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.

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
Show full document text