Ericsson AB

SE-164 80 Stockholm Sweden john.mattsson@ericsson.com

Key exchange without forward secrecy enables passive monitoring. Massive pervasive monitoring attacks relying on key exchange without forward secrecy has been reported, 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 a passive attacker to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. psk_ke does not provide forward secrecy and is NOT RECOMMENDED. This document sets the IANA registration of psk_ke to NOT RECOMMENDED.

Key exchange without forward secrecy enables passive monitoring . Massive pervasive monitoring attacks relying on key exchange without forward secrecy has been reported , 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 a passive attacker to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. All TLS 1.2 cipher suites without forward secrecy has been marked as NOT RECOMMENDED , and static RSA has been forbidden in TLS 1.3 . A large number of TLS profiles forbid use of key exchange without Diffie-Hellman for TLS 1.2 , , . ANSSI states that for all versions of TLS: “The perfect forward secrecy property must be ensured.” 3GPP based their general TLS 1.2 profile on states: “Only cipher suites with AEAD (e.g. GCM) and PFS (e.g. ECDHE, DHE) shall be supported. In addition to the very serious weaknesses of not providing protection against key leakage and enabling passive monitoring , psk_ke has other significant security problems. As stated in , 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 , psk_ke fails yet another one of the fundamental TLS 1.3 security properties, namely “Secrecy of the session keys” . Together with ffdhe, and rsa_pkcs1, psk_ke is one of the bad apples in the TLS 1.3 fruit basket. Organizations like BSI has already produced recommendations regarding TLS 1.3. BSI states regarding psk_ke that it “This mode should only be used in special applications after consultation of an expert.” and has set a deadline of 2026 when psk_ke should not be used at all anymore. Unfortunately psk_ke is marked as “Recommended” in the IANA PskKeyExchangeMode registry. This may 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 has been unwilling to disrecommend psk_ke as IETF has so clearly marked it as “Recommended”. PSK authentication has yet another big inherent weakness as it 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. 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”. Editor’s note: The current IANA action is based on the present very limited single column in the IANA TLS registries. If more granular classifications were possible in the future, it would likely make sense to difference between different use cases where psk_ke might be useful such as very constrained IoT.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. Ericsson Ericsson Ericsson Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in [I-D.ietf-emu-rfc5448bis]. The extension, when negotiated, provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'. This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. Vigil Security Cloudflare Ltd. Ericsson Cloudflare This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) version 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. It discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. It provides advice for applications in various use cases to help meet these assumptions. It also lists the privacy and security properties that are not provided by TLS when external PSKs are used.

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