idnits 2.17.1 draft-schanck-tls-additional-keyshare-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 312 has weird spacing: '...itional v...' -- The document date (April 17, 2017) is 2566 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schanck 3 Internet-Draft University of Waterloo 4 Intended status: Experimental D. Stebila 5 Expires: October 19, 2017 McMaster University 6 April 17, 2017 8 A Transport Layer Security (TLS) Extension For Establishing An 9 Additional Shared Secret 10 draft-schanck-tls-additional-keyshare-00 12 Abstract 14 This document defines a Transport Layer Security (TLS) extension that 15 allows parties to establish an additional shared secret using a 16 second key exchange algorithm and incorporates this shared secret 17 into the TLS key schedule. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 19, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 3 56 2. Additional Key Share Extension . . . . . . . . . . . . . . . 4 57 2.1. ExtensionType . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Existing data structures . . . . . . . . . . . . . . . . 4 59 2.3. AdditionalKeyShare extension . . . . . . . . . . . . . . 4 60 2.3.1. Requirements for use in ClientHello . . . . . . . . . 5 61 2.3.2. Requirements for use in ServerHello . . . . . . . . . 6 62 2.3.3. Requirements for use in HelloRetryRequest . . . . . . 6 63 2.4. Backward Compatibility . . . . . . . . . . . . . . . . . 6 64 2.4.1. Negotiating with a server that does not support the 65 additional_key_share extension . . . . . . . . . . . 6 66 2.4.2. Negotiating with a client that does not support the 67 additional_key_share extension . . . . . . . . . . . 6 68 3. Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Pre-shared key modes and session resumption . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The key schedule of TLS 1.3 [TLS13draft19] is capable of extracting 80 session key material from multiple shared secrets. A notable use of 81 this feature is in forward secret pre-shared key (PSK) modes wherein 82 a PSK is combined with an ephemeral shared secret established through 83 a Diffie-Hellman exchange. While the key schedule can process 84 arbitrary lists of shared secrets, it is currently only possible to 85 incorporate a pre-shared key and a shared secret established through 86 the "key_share" extension. 88 This document defines a TLS ClientHello, HelloRetryRequest, and 89 ServerHello extension of type "additional_key_share" that allows 90 parties to establish an additional shared secret. 92 This document does not define any named groups or key exchange modes. 94 1.1. Use cases 96 One use case is to provide pre- to post-quantum transitional security 97 while hedging against potential weaknesses of post-quantum 98 algorithms. A post-quantum cryptographic algorithm is one that is 99 believed to be resistant to attacks by quantum computers; algorithms 100 based on factoring and discrete log are said to be pre-quantum. 101 Authenticated and confidential channel establishment protocols are 102 said to be secure in a transitional setting if they provide pre- 103 quantum authentication and post-quantum confidentiality. Such 104 protocols provide forward secrecy so long as adversaries do not have 105 quantum computers at the time of session establishment. 107 An additional key share can be used to combine a high-confidence pre- 108 quantum confidentiality mechanism with a more experimental post- 109 quantum confidentiality mechanism without any added risk. 111 One could argue that if post-quantum algorithms are available then 112 they should be used in place of pre-quantum algorithms. However 113 there are several reasons why a user might not want to rely solely on 114 a post-quantum algorithm today. First, confidence in cryptographic 115 assumptions relies in part on the duration and intensity of their 116 study. Most post-quantum assumptions have received less scrutiny 117 than DH or ECDH, and cryptanalysis may progress rapidly as more 118 attention is drawn to these assumptions. Second, the cryptographic 119 community has less experience writing secure implementations of post- 120 quantum algorithms, and one may be concerned that there are yet-to- 121 be-discovered implementation pitfalls and side-channel attacks that 122 could compromise confidentiality. Finally there may be users who are 123 required to use certain pre-quantum algorithms, but who nevertheless 124 desire forward secrecy against post-quantum adversaries. For 125 example, NIST has made it clear that hybrid modes are not 126 incompatible with FIPS 140 validation [NISTPQFAQ]. 128 The simultaneous use of pre-quantum and post-quantum algorithms 129 provides users with the potential of long-term, quantum-resistant 130 confidentiality without any added risk. 132 1.2. Conventions and Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in RFC 137 2119 [RFC2119]. 139 In [TLS13draft19], all asymmetric key exchange modes are either 140 (finite field) Diffie-Hellman or elliptic curve Diffie-Hellman, and 141 the term "named group" is used to identify which group. Some key 142 exchange mechanisms, especially post-quantum mechanisms, are not 143 parameterized by a group. However, we continue to use the term 144 "named group" to identify a key exchange mechanism more broadly. 146 2. Additional Key Share Extension 148 The "additional_key_share" extension replicates the functionality of 149 the "key_share" extension defined in [TLS13draft19], although there 150 are some semantic differences between the two extensions. 152 2.1. ExtensionType 154 This document extends the ExtensionType enum as follows: 156 enum { 157 ..., 158 additional_key_share(XX), 159 (65535) 160 } ExtensionType; 162 2.2. Existing data structures 164 The definition of the AdditionalKeyShare extension requires the 165 KeyShareEntry and NamedGroup structs defined in [TLS13draft19]. 166 NamedGroup is a 2-octet enum. For convenience of the reader, we 167 reproduce the definition of KeyShareEntry from [TLS13draft19] below: 169 struct { 170 NamedGroup group; 171 opaque key_exchange<1..2^16-1>; 172 } KeyShareEntry; 174 2.3. AdditionalKeyShare extension 176 The "extension_data" field of the "additional_key_share" extension 177 contains an "AdditionalKeyShare" value. 179 struct { 180 select (Handshake.msg_type) { 181 case client_hello: 182 KeyShareEntry additional_client_shares<0..2^16-1>; 184 case hello_retry_request: 185 NamedGroup additional_selected_group; 187 case server_hello: 188 KeyShareEntry additional_server_share; 189 }; 190 } AdditionalKeyShare; 192 additional_client_shares A list of offered KeyShareEntry values in 193 descending order of client preference. 195 additional_selected_group A mutually supported key exchange 196 algorithm that the server is willing to negotiate if the client 197 sends an "additional_key_share" extension in a new ClientHello. 199 additional_server_share A single KeyShareEntry value that is in the 200 same NamedGroup as one of the client's shares. 202 2.3.1. Requirements for use in ClientHello 204 The client MUST NOT send the "additional_key_share" extension without 205 sending the "key_share" extension. The client MAY send an empty 206 "additional_client_shares" vector when requesting a 207 HelloRetryRequest, but SHOULD NOT do so otherwise. 209 The client MUST NOT offer a KeyShareEntry value for a NamedGroup that 210 is not listed in the "supported_groups" extension. 212 The client MUST NOT offer multiple KeyShareEntry values in the 213 "additional_client_shares" vector for the same NamedGroup. This is 214 because the "additional_server_share" value of the server's 215 "additional_key_share" extension must uniquely identify the client 216 share to which it corresponds. 218 The client MAY offer a KeyShareEntry value in 219 "additional_client_shares" for a NamedGroup that they offered in 220 their "key_share" extension, as this causes no ambiguity. 222 Each value in the client's "additional_client_shares" vector MUST be 223 generated independently. The independence requirement extends to the 224 KeyShareEntry values offered in the "key_share" extension. In 225 particular, the client MUST NOT offer KeyShareEntry values in 226 "additional_key_share" that duplicate the contents of KeyShareEntry 227 values offered in "key_share". 229 The server MAY check for violations of these rules and MAY abort the 230 connection with a fatal "illegal_parameter" alert if a rule is 231 violated. 233 2.3.2. Requirements for use in ServerHello 235 The server MUST NOT send a KeyShareEntry for any NamedGroup not 236 indicated in the "supported_groups" extension. The server MUST NOT 237 send a KeyShareEntry for a NamedGroup that does not match one of the 238 client's offers. 240 2.3.3. Requirements for use in HelloRetryRequest 242 The server MAY send HelloRetryRequest based on the contents of the 243 client's "additional_client_shares" vector. The client processes 244 this message as in Section 4.2.5 of [TLS13draft19]. 246 2.4. Backward Compatibility 248 2.4.1. Negotiating with a server that does not support the 249 additional_key_share extension 251 If a server does not provide an "additional_key_share" extension in 252 its ServerHello, the client MAY abort the handshake with a 253 "missing_extension" alert, or the client MAY finish the handshake 254 based on the server's "key_share" extension. (The latter allows a 255 client to negotiate a connection with a server who does not recognize 256 this extension without retrying the handshake.) 258 2.4.2. Negotiating with a client that does not support the 259 additional_key_share extension 261 If a client does not provide an "additional_key_share" extension in 262 its ClientHello, the server MAY abort the handshake with a 263 "missing_extension" alert, or the server MAY finish the handshake 264 based on the client's "key_share" extension. 266 If the server chooses to finish the handshake based on the client's 267 "key_share" extension, this allows a server that supports both pre- 268 quantum and post-quantum key exchange to negotiate a connection with 269 a client that does not recognize this extension and only supports 270 pre-quantum key exchange. 272 3. Key Schedule 274 The presence of the "additional_key_share" extension alters the 275 derivation of the master secret. The key schedule employed by TLS 276 1.3 handles a list of input secrets by iteratively invoking HKDF- 277 Extract. When the "additional_key_share" extension is not present, 278 secrets are processed in the following order: 280 o PSK 282 o (EC)DHE shared secret. 284 When an additional secret is derived through "additional_key_share" 285 the order is: 287 o PSK 289 o (EC)DHE shared secret 291 o Additional secret. 293 0 294 | 295 v 296 PSK -> HKDF-Extract = Early Secret 297 | 298 +--> Derive-Secret(...) = binder_key 299 +--> Derive-Secret(...) = client_early_traffic_secret 300 +--> Derive-Secret(...) = early_exporter_secret 301 | 302 v 303 Derive-Secret(., "derived secret", "") 304 | 305 v 306 (EC)DHE -> HKDF-Extract 307 | 308 v 309 Derive-Secret(., "derived secret", "") 310 | 311 | 312 Additional v 313 Secret -> HKDF-Extract = Handshake Secret 314 | 315 +--> Derive-Secret(...) = client_handshake_traffic_secret 316 +--> Derive-Secret(...) = server_handshake_traffic_secret 317 | 318 v 319 Derive-Secret(., "derived secret", "") 320 | 321 v 322 0 -> HKDF-Extract = Master Secret 323 | 324 +--> Derive-Secret(...) = client_traffic_secret_0 325 +--> Derive-Secret(...) = server_traffic_secret_0 326 +--> Derive-Secret(...) = exporter_secret 327 +--> Derive-Secret(...) = resumption_master_secret 329 4. Pre-shared key modes and session resumption 331 [[FOR DISCUSSION]] 333 TLS 1.3 allows the client to restrict the use of PSKs that they 334 provide in ClientHello through the "psk_key_exchange_modes" 335 extension. The client may, for instance, request that the PSK only 336 be used in a PSK+(EC)DHE mode, so as to ensure that the resumed 337 session has forward secrecy. 339 If the client sends "additional_key_share" in an initial ClientHello, 340 it is reasonable to expect that they will want to use 341 "additional_key_share" in PSK-resumption. It is possible to 342 accomodate such a client by defining a new PskKeyExchangeMode, 343 however there is a caveat in doing so that we feel it is worth 344 pointing out. 346 Suppose that a PSK has been established through some combination of 347 pre-quantum and post-quantum mechanisms, as in our proposed use case. 348 This PSK is treated as long-term key material during resumption, so a 349 "psk_dhe_ke" mode would not be sufficient to preserve the security 350 properties of the initial handshake, namely forward secrecy against 351 post-quantum adversaries. To avoid this, a post-quantum mechanisms 352 must be used in the resumption handshake. 354 It is not sufficient to require the use of "additional_key_share" 355 during resumption, as this could be used to combine two pre-quantum 356 mechanisms. 358 Possible remedies: 360 o Add a new PskKeyExchangeMode that enforces the use of the same 361 NamedGroups that were used to establish the initial secret. enum 362 { ..., psk_same_groups_ke(XX), (255) } PskKeyExchangeMode; 364 o Add a new PskKeyExchangeMode for "transitional" security enum { 365 ..., psk_transitional_ke(XX), (255) } PskKeyExchangeMode; 367 5. Security Considerations 369 This document does not change the intended security properties of 370 TLS. In particular, it retains the goals of "establishing the same 371 session key" and "secrecy of the session key" as described in 372 Appendix E.1 of [TLS13draft19]. 374 6. IANA Considerations 376 IANA [SHALL add/has added] a new entry to the TLS extensions 377 ExtensionType values registry for "additional_key_share". 379 7. References 381 7.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 7.2. Informative References 390 [NISTPQFAQ] 391 NIST, "Post-Quantum Crypto Standardization FAQ", April 392 2017, . 395 [TLS13draft19] 396 Rescorla, E., "The Transport Layer Security (TLS) Protocol 397 Version 1.3", March 2017, . 400 Authors' Addresses 402 John M. Schanck 403 University of Waterloo 404 200 University Avenue West 405 Waterloo, ON N2L 3G1 406 Canada 408 Email: jschanck@uwaterloo.ca 410 Douglas Stebila 411 McMaster University 412 1280 Main Street West 413 Hamilton, ON L8S 4L8 414 Canada 416 Email: stebilad@mcmaster.ca