idnits 2.17.1 draft-mattsson-tls-psk-ke-dont-dont-dont-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2021) is 1067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-emu-aka-pfs-05 == Outdated reference: A later version (-06) exists of draft-ietf-tls-external-psk-guidance-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuss Mattsson 3 Internet-Draft Ericsson 4 Intended status: Informational May 18, 2021 5 Expires: November 19, 2021 7 Key Exchange Without Forward Secrecy is NOT RECOMMENDED 8 draft-mattsson-tls-psk-ke-dont-dont-dont-01 10 Abstract 12 Key exchange without forward secrecy enables passive monitoring. 13 Massive pervasive monitoring attacks relying on key exchange without 14 forward secrecy has been reported, and many more have likely happened 15 without ever being reported. If key exchange without Diffie-Hellman 16 is used, access to the long-term authentication keys enables a 17 passive attacker to compromise past and future sessions. Entities 18 can get access to long-term key material in different ways: physical 19 attacks, hacking, social engineering attacks, espionage, or by simply 20 demanding access to keying material with or without a court order. 21 psk_ke does not provide forward secrecy and is NOT RECOMMENDED. This 22 document sets the IANA registration of psk_ke to NOT RECOMMENDED. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 19, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 3.2. Informative References . . . . . . . . . . . . . . . . . 4 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Key exchange without forward secrecy enables passive monitoring 70 [RFC7258]. Massive pervasive monitoring attacks relying on key 71 exchange without forward secrecy has been reported [Heist] 72 [I-D.ietf-emu-aka-pfs], and many more have likely happened without 73 ever being reported. If key exchange without Diffie-Hellman is used, 74 access to the long-term authentication keys enables a passive 75 attacker to compromise past and future sessions. Entities can get 76 access to long-term key material in different ways: physical attacks, 77 hacking, social engineering attacks, espionage, or by simply 78 demanding access to keying material with or without a court order. 80 All TLS 1.2 [RFC5246] cipher suites without forward secrecy has been 81 marked as NOT RECOMMENDED [RFC8447], and static RSA has been 82 forbidden in TLS 1.3 [RFC8446]. A large number of TLS profiles 83 forbid use of key exchange without Diffie-Hellman for TLS 1.2 84 [RFC7540], [ANSSI], [TS3GPP]. 86 o ANSSI states that for all versions of TLS: "The perfect forward 87 secrecy property must be ensured." 89 o 3GPP based their general TLS 1.2 profile on [RFC7540] states: 90 "Only cipher suites with AEAD (e.g. GCM) and PFS (e.g. ECDHE, 91 DHE) shall be supported. 93 In addition to the very serious weaknesses of not providing 94 protection against key leakage and enabling passive monitoring 95 [RFC7258], psk_ke has other significant security problems. As stated 96 in [RFC8446], psk_ke does not fulfill one of the fundamental TLS 1.3 97 security properties, namely "Forward secret with respect to long-term 98 keys". When the PSK is a group key, which is now formally allowed in 99 TLS 1.3 [I-D.ietf-tls-external-psk-guidance], psk_ke fails yet 100 another one of the fundamental TLS 1.3 security properties, namely 101 "Secrecy of the session keys" [Akhmetzyanova19] 102 [I-D.ietf-tls-external-psk-guidance]. 104 Together with ffdhe, and rsa_pkcs1, psk_ke is one of the bad apples 105 in the TLS 1.3 fruit basket. Organizations like BSI [BSI] has 106 already produced recommendations regarding TLS 1.3. 108 o BSI states regarding psk_ke that it "This mode should only be used 109 in special applications after consultation of an expert." and has 110 set a deadline of 2026 when psk_ke should not be used at all 111 anymore. 113 Unfortunately psk_ke is marked as "Recommended" in the IANA 114 PskKeyExchangeMode registry. This may weaken security in deployments 115 following the "Recommended" column. Introducing TLS 1.3 in 3GPP had 116 the unfortunate and surprising effect of drastically lowering the 117 minimum security when TLS is used with PSK authentication. Some 118 companies in 3GPP has been unwilling to disrecommend psk_ke as IETF 119 has so clearly marked it as "Recommended". 121 PSK authentication has yet another big inherent weakness as it does 122 not provide "Protection of endpoint identities". It could be argued 123 that PSK authentication should be not recommended solely based on 124 this significant privacy weakness. 126 This document updates the PskKeyExchangeMode registry under the 127 Transport Layer Security (TLS) Parameters heading. For psk_ke the 128 "Recommended" value has been set to "N". 130 Editor's note: The current IANA action is based on the present very 131 limited single column in the IANA TLS registries. If more granular 132 classifications were possible in the future, it would likely make 133 sense to difference between different use cases where psk_ke might be 134 useful such as very constrained IoT. 136 1.1. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2. IANA Considerations 146 IANA is requested to update the PskKeyExchangeMode registry under the 147 Transport Layer Security (TLS) Parameters heading. For psk_ke the 148 "Recommended" value has been set to "N". 150 3. References 152 3.1. Normative References 154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 155 Requirement Levels", BCP 14, RFC 2119, 156 DOI 10.17487/RFC2119, March 1997, 157 . 159 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 160 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 161 May 2017, . 163 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 164 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 165 . 167 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 168 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 169 . 171 3.2. Informative References 173 [Akhmetzyanova19] 174 Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. 175 Sokolov, "Continuing to reflect on TLS 1.3 with external 176 PSK", April 2019, . 178 [ANSSI] Agence nationale de la securite des systemes 179 d'information, ., "Security Recommendations for TLS", 180 January 2017, . 183 [BSI] Bundesamt fuer Sicherheit in der Informationstechnik, ., 184 "Technical Guideline TR-02102-2 Cryptographic Mechanisms: 185 Recommendations and Key Lengths Part 2 - Use of Transport 186 Layer Security (TLS)", January 2021, . 190 [Heist] The Intercept, ., "How Spies Stole the Keys to the 191 Encryption Castle", February 2015, 192 . 194 [I-D.ietf-emu-aka-pfs] 195 Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward 196 Secrecy for the Extensible Authentication Protocol Method 197 for Authentication and Key Agreement (EAP-AKA' PFS)", 198 draft-ietf-emu-aka-pfs-05 (work in progress), October 199 2020. 201 [I-D.ietf-tls-external-psk-guidance] 202 Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, 203 "Guidance for External PSK Usage in TLS", draft-ietf-tls- 204 external-psk-guidance-02 (work in progress), February 205 2021. 207 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 208 (TLS) Protocol Version 1.2", RFC 5246, 209 DOI 10.17487/RFC5246, August 2008, 210 . 212 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 213 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 214 2014, . 216 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 217 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 218 DOI 10.17487/RFC7540, May 2015, 219 . 221 [TS3GPP] 3GPP, ., "TS 33.210 Network Domain Security (NDS); IP 222 network layer security", July 2020, 223 . 226 Acknowledgements 228 The authors want to thank Ari Keraenen for their valuable comments 229 and feedback. 231 Author's Address 232 John Preuss Mattsson 233 Ericsson AB 234 SE-164 80 Stockholm 235 Sweden 237 Email: john.mattsson@ericsson.com