Key Exchange Without Forward Secrecy is NOT RECOMMENDED

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 3 July 2023.¶

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

Key exchange without forward secrecy enables passive monitoring [RFC7258]. Massive pervasive monitoring attacks using key exfiltration and made possible by key exchange without forward secrecy has been reported [Heist], and many more have likely happened without ever being reported. If key exchange without Diffie-Hellman is used, access to the long-term authentication keys enables passive attackers to compromise all past and future connections. Malicious actors can get access to long-term keys in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. Exfiltration attacks are a major cybersecurity threat [Exfiltration].¶

All cipher suites without forward secrecy has been marked as NOT RECOMMENDED in TLS 1.2 [RFC8447], and static RSA and DH are forbidden in TLS 1.3 [RFC8446]. A large number of TLS profiles forbid the use of key exchange without Diffie-Hellman [RFC9113] [ANSSI-TLS] [T3GPP.33.210].¶

• ANSSI states that for all versions of TLS: "The perfect forward secrecy property must be ensured" [ANSSI-TLS].¶
• The general 3GPP TLS profile follows [RFC9113] and states: "Only cipher suites with AEAD (e.g., GCM) and PFS (e.g. ECDHE, DHE) shall be supported" [T3GPP.33.210].¶

Unfortunately TLS 1.3 allows key exchange without forward secrecy in both full handshakes and resumption handshakes with psk_ke. As stated in [RFC8446], psk_ke does not fulfill one of the fundamental TLS 1.3 security properties, namely "Forward secret with respect to long-term keys". When the PSK is a group key, which is now formally allowed in TLS 1.3 [RFC9257], psk_ke fails yet another one of the fundamental TLS 1.3 security properties, namely "Secrecy of the session keys" [Akhmetzyanova] [RFC9257]. PSK authentication has yet another big inherent weakness as it often does not provide "Protection of endpoint identities". It could be argued that PSK authentication should be not recommended solely based on this significant privacy weakness. The 3GPP radio access network that to a large degree relies on PSK are fixing the vulnerabilities by augmenting PSK with ECIES and ECDHE, see Annex C of [T3GPP.33.501] and [I-D.ietf-emu-aka-pfs].¶

Together with rsa_pkcs1, psk_ke is one of the bad apples in the TLS 1.3 fruit basket. Organizations like BSI [BSI] has already produced recommendations regarding its deprecation.¶

• BSI states regarding psk_ke that "This mode should only be used in special applications after consultation of an expert." and has set a deadline that use is only allowed until 2026.¶

Two essential zero trust principles are to assume that breach is inevitable or has likely already occurred [NSA-ZT], and to minimize impact when breach occur [NIST-ZT]. One type of breach is key compromise or key exfiltration. Different types of exfiltration is defined and discussed in [RFC7624]. Static exfiltration where the keys are transferred once has a lower risk profile than dynamic exfiltration where keying material or content is transferred to the attacker frequently. Forcing an attacker to do dynamic exfiltration should be considered best practice. This significantly increases the risk of discovery for the attacker.¶

One way to force an attacker to do dynamic exfiltration is to frequently rerun ephemeral Diffie-Hellman. For IPsec, ANSSI [ANSSI-PFS] recommends enforcing periodic rekeying with ephemeral Diffie-Hellman, e.g., every hour and every 100 GB of data, in order to limit the impact of a key compromise. This should be considered best practice for all protocols and systems. The Double Ratchet Algorithm in the Signal protocol [Signal] enables very frequent use of ephemeral Diffie-Hellman. The practice of frequently rerunning ephemeral Diffie-Hellman follows directly from zero trust principles.¶

In TLS 1.3, the application_traffic_secret can be rekeyed using key_update, a resumption handshake, or a full handshake. The term forward secrecy is not very specific, and it is often better to talk about the property that compromise of key A does not lead to compromise of key B. Figure 1 illustrates the impact of some examples of static key exfiltration when psk_ke, key_update, and (ec)dhe are used for rekeying. Each time period Tᵢ uses a single application_traffic_secret. ✘ means that the attacker has access to the application_traffic_secret in that time period and can passively eavesdrop on the communication. ✔ means that the attacker does not have access to the application_traffic_secret. Exfiltration and frequently rerunning EC(DHE) is discussed in Appendix F of [I-D.ietf-tls-rfc8446bis].¶

With modern algorithms like x25519 [RFC7748], ephemeral Diffie-Hellman introduces negligible overhead. The public keys are 32 bytes long and the operations takes 63 microseconds per endpoint on a single core AMD Ryzen 9 5950X [eBACS-DH]. Ephemeral key exchange with the quantum-restistant algorithm Kyber that NIST will standardize is even faster, especially for the TLS server [eBACS-KEM].¶

Unfortunately, psk_ke is marked as "Recommended" in the IANA PskKeyExchangeMode registry. This may severely weaken security in deployments following the "Recommended" column. Introducing TLS 1.3 in 3GPP had the unfortunate and surprising effect of drastically lowering the minimum security when TLS is used with PSK authentication. Some companies in 3GPP have been unwilling to mark psk_ke as not recommended as it is so clearly marked as "Recommended" by the IETF. By labeling psk_ke as "Recommended", IETF is legitimizing and implicitly promoting bad security practice.¶

This document updates the PskKeyExchangeMode registry under the Transport Layer Security (TLS) Parameters heading. For psk_ke the "Recommended" value has been set to "N".¶

2. IANA Considerations

IANA is requested to update the PskKeyExchangeMode registry under the Transport Layer Security (TLS) Parameters heading. For psk_ke the "Recommended" value has been set to "N".¶

Acknowledgements

The authors want to thank Ari Keränen for his valuable comments and feedback.¶

Author's Address