]> Ericsson AB

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

Massive pervasive monitoring attacks using key exfiltration and made possible by key exchange without forward secrecy have been reported. If key exchange without Diffie-Hellman is used, static exfiltration of 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. The use of psk_ke is not following zero trust principles of minimizing the impact of breach and governments have already made deadlines for its deprecation. This document updates the IANA PskKeyExchangeMode registry by setting the "Recommended" value for psk_ke to "N". About This Document Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security (tls) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Key exchange without forward secrecy enables passive monitoring . Massive pervasive monitoring attacks using key exfiltration and made possible by key exchange without forward secrecy have 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 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 . All cipher suites without forward secrecy have been marked as NOT RECOMMENDED in TLS 1.2 , and static RSA and DH are forbidden in TLS 1.3 . A large number of TLS profiles and implementations forbid the use of key exchange without Diffie-Hellman.

• ANSSI states that for all versions of TLS: "The perfect forward secrecy property must be ensured" .
• The general 3GPP TLS 1.2 profile follows and states: "Only cipher suites with AEAD (e.g., GCM) and PFS (e.g. ECDHE, DHE) shall be supported" .
• BoringSSL does not implement psk_ke, so TLS 1.3 resumption always incorporates fresh key material .

Unfortunately, TLS 1.3 allows key exchange without forward secrecy in both full handshakes and resumption handshakes with the psk_ke. 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" . 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 and . Together with 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 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 , and to minimize impact when breach occur . One type of breach is key compromise or key exfiltration. Different types of exfiltration are defined and discussed in . 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 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 enables very frequent use of ephemeral Diffie-Hellman. The practice of frequently rerunning ephemeral Diffie-Hellman follows directly from the two zero trust principles mentioned above. 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. 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 .

Impact of static key exfiltration in time period T3 when psk_ke, key_update, and (ec)dhe are used. rekeying with key_update static exfiltration of application_traffic_secret in T₃: +-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+ | ✔ | ✔ | ✔ | ✘ | ✘ | ✘ | ✘ | ✘ | ... | ✘ | ✘ | +-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+ T₀ T₁ T₂ T₃ T₄ T₅ T₆ T₇ ... Tₙ₋₁ Tₙ <---------------------------------------------> rekeying with (ec)dhe static exfiltration of all keys in T₃: +-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+ | ✔ | ✔ | ✔ | ✘ | ✔ | ✔ | ✔ | ✔ | ... | ✔ | ✔ | +-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+ T₀ T₁ T₂ T₃ T₄ T₅ T₆ T₇ ... Tₙ₋₁ Tₙ <---> ]]>

Modern ephemeral key exchange algorithms like x25519 are very fast and have small message overhead. The public keys are 32 bytes long and the cryptographic operations take 53 microseconds per endpoint on a single core AMD Ryzen 5 5560U . Ephemeral key exchange with the quantum-resistant algorithm Kyber that NIST will standardize is even faster. For the current non-standardized version of Kyber512 the cryptographic operations take 12 microseconds for the client and 8 microseconds for the server . 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".

Terminology 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 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".

References Normative References 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. Informative References Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. 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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. Ericsson Ericsson Ericsson Ericsson Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, 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. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication method, with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides 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. Mozilla 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, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations.

Acknowledgements The authors want to thank , , and for their valuable comments and feedback.