idnits 2.17.00 (12 Aug 2021) /tmp/idnits31137/draft-davidben-tls-universal-psk-00.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 draft header indicates that this document updates draft-ietf-tls-tls13, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 14, 2018) is 1430 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Benjamin 3 Internet-Draft Google 4 Updates: draft-ietf-tls-tls13 (if June 14, 2018 5 approved) 6 Intended status: Informational 7 Expires: December 16, 2018 9 Universal PSKs for TLS 10 draft-davidben-tls-universal-psk-00 12 Abstract 14 This document describes universal PSKs (Pre-Shared Keys) for TLS. 15 Universal PSKs abstract the TLS 1.3 requirement that each PSK can 16 only be used with a single hash function. This allows PSKs to be 17 provisioned without depending on details of the TLS negotiation, 18 which may change as TLS evolves. Additionally, this document 19 describes a compatibility profile for using TLS 1.3 with PSKs 20 provisioned for the TLS 1.2 PSK mechanism. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 16, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Universal PSKs . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Compatibility with TLS 1.2 PSKs . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 TLS 1.3 [I-D.ietf-tls-tls13] provides a PSK mechanism to authenticate 69 connections with symmetric keys provisioned externally to TLS. 70 However, unlike the analogous mechanism in earlier versions of TLS 71 [RFC4279], TLS 1.3 PSKs must be constrained to a single hash 72 function. 74 While this constraint simplifies the analysis and does not hinder the 75 resumption use case, it is cumbersome for external PSKs. It ties the 76 PSK provisioning process to details of TLS. The application protocol 77 configuring TLS is usually abstracted from TLS's details. In some 78 cases, the underlying TLS implementation may even be updated without 79 changes to the calling application. 81 Additionally, applications using TLS with PSKs typically require some 82 PSK be negotiated, so parameter selection must follow the hash 83 constraint. In contrast, applications using resumption typically 84 allow the session to be declined in favor of a full handshake, so 85 parameter selection may complete independently of this constraint. 86 Switching the order of the selections for external PSKs adds 87 implementation complexity and complicates analysis of the server's 88 configuration. 90 This document resolves these issues by adding an extra key derivation 91 step to reuse the same secret for all TLS 1.3 KDF hashes, including 92 hashes to be defined in the future. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Universal PSKs 102 A universal PSK consists of the following: 104 o An identity. This is a public opaque byte string. 106 o A secret. This is a secret opaque byte string. 108 o A KDF hash function for use with HKDF [RFC5869]. Unless otherwise 109 specified, this is SHA-256 [SHS]. 111 In this section's diagrams, "0" refers to a string of zero bytes with 112 length matching the KDF hash. Derive-Secret refers to the 113 corresponding function defined in TLS 1.3, using the KDF hash. 115 A universal PSK is advertised in TLS 1.3 by including the identity 116 and index in the "pre_shared_key" extension of the ClientHello and 117 ServerHello, respectively. The binder value is computed as in TLS 118 1.3, however, the binder key is derived with the universal PSK's 119 secret and KDF hash as follows: 121 extracted = HKDF-Extract(universal_psk, 0) 122 binder_key = Derive-Secret(extracted, "univ binder", identity) 124 Unlike other PSKs, a universal PSK may be negotiated with any cipher 125 suite, including those using a different KDF hash than the PSK. When 126 negotiated, the universal PSK's secret is used to derive a hash- 127 specific TLS 1.3 PSK as follows: 129 If the negotiated cipher suite uses a SHA-256 KDF hash, the PSK is 130 derived as follows: 132 extracted = HKDF-Extract(universal_psk, 0) 133 psk = Derive-Secret(extracted, "sha256 psk", identity) 135 If the negotiated cipher suite uses a SHA-384 KDF hash, the PSK is 136 derived as follows: 138 extracted = HKDF-Extract(universal_psk, 0) 139 psk = Derive-Secret(extracted, "sha384 psk", identity) 141 These PSKs are used in the key schedule as specified in TLS 1.3, 142 except that they are not used to derive the "binder_key" value, 143 already derived above. 145 Future KDF hash algorithms added to TLS 1.3 MUST specify how to 146 compute the derived PSK from a universal PSK. Future versions of TLS 147 MUST specify how to negotiate a universal PSK and how to use it when 148 negotiated. Note, however, all versions of TLS using the 149 "pre_shared_key" extension to negotiate PSKs MUST use the same binder 150 derivation, while the derived PSKs SHOULD be version-specific. 152 Universal PSKs are not defined for use with 0-RTT. 0-RTT requires 153 specifying many negotiated TLS parameters, which is not compatible 154 with the goals of this specification. However, a client MAY choose 155 to offer a universal PSK alongside a resumption-based or other 0-RTT- 156 compatible PSK. The universal PSK is then analogous to the full 157 handshake option when resumption is declined. 159 Note that whether a PSK is a universal PSK is not explicitly 160 negotiated in TLS. It is provisioned alongside the secret itself 161 when the PSK is pre-shared. This would typically be specified in the 162 application protocol. 164 3. Compatibility with TLS 1.2 PSKs 166 Universal PSKs are only defined for use with TLS 1.3 and future 167 versions of TLS. New protocols using TLS and PSKs SHOULD require TLS 168 1.3 or later. However, this may not be possible for existing 169 protocols already using PSKs with TLS 1.2. This section describes a 170 compatibility profile for upgrading to TLS 1.3. 172 A PSK provisioned for TLS 1.2 and earlier MUST NOT be used either as 173 a universal PSK secret or directly as a TLS 1.3 PSK. This would 174 invalidate security analysis of the two protocols individually. 175 Instead, these PSKs MAY be used to derive a universal PSK. The 176 identity is the TLS 1.2 PSK's identity. The secret is derived using 177 the TLS 1.2 PRF function described in Section 5 of [RFC5246] with 178 SHA-256 as the hash function, as follows: 180 universal_psk = PRF(pre_master_secret, "universal psk", "")[:32] 182 "pre_master_secret" is specified with the structure below, setting 183 "psk" to TLS 1.2 PSK and "other_secret" to a string of all zeroes of 184 the same length as the TLS 1.2 PSK. 186 struct { 187 opaque other_secret<0..2^16-1> 188 opaque psk<0..2^16-1> 189 } 191 Note this encoding and derivation aligns with the PSK's conversion to 192 a premaster secret and then a master secret in [RFC5246]. 194 Applications using this derivation are necessarily impacted by 195 portions of TLS 1.2. New applications without a TLS 1.2 legacy 196 SHOULD NOT use this derivation and instead SHOULD provision universal 197 PSKs directly. Applications using it SHOULD migrate to this state 198 after migrating to TLS 1.3. 200 4. Security Considerations 202 The security analysis for TLS 1.3 relies on each PSK having a single 203 use. Using a TLS 1.3 PSK with two different hashes or with TLS 1.2 204 means the same secret is used with different KDF functions, 205 invalidating that analysis. Universal PSKs instead derive 206 independent PSKs using different KDF labels, so each derived PSK 207 continues to have only a single use. The PSK identity is 208 additionally included in each derivation to give a stronger 209 connection between the identity and PSK. 211 TLS 1.3's analysis also depends on the KDF and MAC used to compute 212 the PSK binder being collision-resistant. This document uses the 213 same derivation as TLS 1.3, but with a different label and initial 214 secret, so the collision-resistance properties carry over. 216 In [RFC5246], TLS 1.2 PSKs are used in premaster secret to master 217 secret derivation. Section 3 aligns with that derivation, using a 218 different label so the secret is derived independently. Note, 219 however, that TLS 1.2 PSKs are not always associated with a single 220 hash function, so they depend on stronger assumptions about hash 221 functions than TLS 1.3 PSKs. The compatibility derivation is 222 unavoidably dependent on this as well. It uses SHA-256, but some TLS 223 1.2 cipher suites use SHA-384, and earlier versions of TLS use an MD5 224 and SHA-1 concatenation. 226 Additionally, labels in the TLS 1.2 PRF function are not delimited 227 from the seed parameter when concatenated. The labels in use thus 228 must not only be distinct, but also prefix-free. This document 229 registers its new TLS 1.2 label in the TLS Exporter Label registry. 230 This registry is required by [RFC5705] to be prefix-free. 232 5. IANA Considerations 234 This document updates the note in the TLS Exporter Label registry 235 to read as follows: 237 Note: (1) These entries are reserved and MUST NOT be used for the 238 purpose described in RFC 5705, in order to avoid confusion with 239 similar, but distinct, use in the referenced document. 241 It additionally registers the label "universal psk". The "Note" 242 column is marked with (1). 244 6. Acknowledgements 246 The author would like to thank Karthikeyan Bhargavan, Matt Caswell, 247 Eric Rescorla, and Victor Vasiliev for discussions and feedback which 248 led to this design. 250 7. Normative References 252 [I-D.ietf-tls-tls13] 253 Rescorla, E., "The Transport Layer Security (TLS) Protocol 254 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 255 March 2018. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 263 Ciphersuites for Transport Layer Security (TLS)", 264 RFC 4279, DOI 10.17487/RFC4279, December 2005, 265 . 267 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 268 (TLS) Protocol Version 1.2", RFC 5246, 269 DOI 10.17487/RFC5246, August 2008, 270 . 272 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 273 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 274 March 2010, . 276 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 277 Key Derivation Function (HKDF)", RFC 5869, 278 DOI 10.17487/RFC5869, May 2010, 279 . 281 [SHS] Dang, Q., "Secure Hash Standard", National Institute of 282 Standards and Technology report, 283 DOI 10.6028/nist.fips.180-4, July 2015. 285 Author's Address 287 David Benjamin 288 Google 289 355 Main St 290 Cambridge, MA 02142 291 USA 293 Email: davidben@google.com