RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2

RFC 10015<br>Deprecating Obsolete Key Exchanges in (D<br>July 2026

Aviram<br>Standards Track<br>[Page]

Stream:<br>Internet Engineering Task Force (IETF)<br>RFC:<br>10015<br>Updates:

4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, 9325<br>Category:<br>Standards Track<br>Published:

July 2026

ISSN:<br>2070-1721<br>Author:

N. Aviram

RFC 10015

Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2

Abstract

For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over<br>a finite field and RSA. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH)<br>cipher suites.¶

These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are<br>deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected<br>algorithms or does not share the relevant configuration options.<br>(There is no DTLS version 1.1.)¶

This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469,<br>5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 to either deprecate or<br>discourage the use of cipher suites using the above key exchange<br>methods in (D)TLS 1.2 connections.¶

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force<br>(IETF). It represents the consensus of the IETF community. It has<br>received public review and has been approved for publication by<br>the Internet Engineering Steering Group (IESG). Further<br>information on Internet Standards is available in Section 2 of<br>RFC 7841.¶

Information about the current status of this document, any<br>errata, and how to provide feedback on it may be obtained at<br>https://www.rfc-editor.org/info/rfc10015.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the<br>document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal<br>Provisions Relating to IETF Documents<br>(https://trustee.ietf.org/license-info) in effect on the date of<br>publication of this document. Please review these documents<br>carefully, as they describe your rights and restrictions with<br>respect to this document. Code Components extracted from this<br>document must include Revised BSD License text as described in<br>Section 4.e of the Trust Legal Provisions and are provided without<br>warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

(D)TLS 1.2 supports a variety of key exchange algorithms, including RSA, Diffie-Hellman (DH)<br>over a finite field, and Elliptic Curve Diffie-Hellman (ECDH).¶

DH key exchange, over any group, comes in ephemeral and non-ephemeral<br>varieties. Non-ephemeral DH algorithms use static DH public keys included in<br>the authenticating peer's certificate; see [RFC4492] for discussion. In<br>contrast, ephemeral DH algorithms use ephemeral DH public keys sent in the<br>handshake and authenticated by the peer's certificate. Ephemeral and non-ephemeral finite field DH<br>algorithms are called DHE and DH (or FFDHE and FFDH), respectively,<br>and ephemeral and non-ephemeral elliptic curve DH algorithms are<br>called ECDHE and ECDH, respectively [RFC4492].¶

In general, non-ephemeral cipher suites are not recommended due to their lack of<br>forward secrecy. Moreover, as demonstrated by the Raccoon attack [RACCOON] on finite field DH, public key reuse (either via non-ephemeral cipher suites or reused keys with<br>ephemeral cipher suites) can lead to timing side channels that may leak connection<br>secrets. For ECDH, invalid curve attacks similarly exploit secret<br>reuse in order to break security [ICA], further demonstrating the risk of reusing<br>public keys. While both side channels can be avoided in implementations, experience<br>shows that in practice, implementations may fail to thwart such attacks due to the<br>complexity and number of the required mitigations.¶

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

At a rough glance, the problems affecting FFDHE in (D)TLS 1.2 are as follows:¶

FFDHE suffers from interoperability problems because there is no mechanism for<br>negotiating the group, and some implementations only support small group sizes<br>(see [RFC7919], Section 1).¶

FFDHE groups may have small subgroups, which enables several attacks<br>[SUBGROUPS]. When presented with a custom, non-standardized FFDHE group, a handshaking client cannot practically verify that the group chosen by the server does not suffer from this problem. There is also no mechanism for such handshakes to fall back to other key exchange parameters that are acceptable to the client.<br>Custom FFDHE groups are widespread (as a result of advice based on [WEAK-DH]).<br>Therefore, clients cannot simply reject handshakes that present custom, and thus potentially dangerous, groups.¶

In...