idnits 2.17.1 draft-whyte-qsh-tls13-04.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 766 has weird spacing: '... be the outco...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (2017-03-31) is 2555 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SECG' is mentioned on line 98, but not defined == Missing Reference: 'TBD' is mentioned on line 482, but not defined == Unused Reference: 'FIPS180' is defined on line 829, but no explicit reference was found in the text == Unused Reference: 'FIPS186' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'H2020' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'HOF15' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'LIN11' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'MCBIT' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'MCELI' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC5990' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC5859' is defined on line 911, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-whyte-qsh-tls12-00 == Outdated reference: A later version (-02) exists of draft-whyte-select-pkc-qsh-00 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT W. Whyte 3 Intended Status: Experimental Security Innovation 4 Expires: 2017-XX-YY Z. Zhang 5 Security Innovation 6 S. Fluhrer 7 Cisco Systems 8 O. Garcia-Morchon 9 Philips 10 2017-03-31 12 Quantum-Safe Hybrid (QSH) Key Exchange 13 for Transport Layer Security (TLS) version 1.3 14 draft-whyte-qsh-tls13-04.txt 16 Abstract 18 This document describes the Quantum-Safe Hybrid Key Exchange, a 19 mechanism for providing modular design for quantum-safe cryptography 20 to be adopted in the handshake for the Transport Layer Security (TLS) 21 protocol version 1.3. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 2017-XX-YY. 46 Update from last version: redesign of the approach to suite latest 47 TLS1.3 draft 18. 49 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Modular design for quantum-safe key exchange . . . . . . . . . 5 56 3.1. Additional Quantum-Safe Key Exchanges . . . . . . . . . . 6 57 3.2. Hybrid Key Exchanges . . . . . . . . . . . . . . . . . . . 8 58 3.2.1. Hybrid Key Exchange within ClientHello . . . . . . . . 8 59 3.2.1.1. Hybrid Key Exchange within the supported_groups 60 extension . . . . . . . . . . . . . . . . . . . . 8 61 3.2.1.1. Hybrid Key Exchange within the key_share 62 extension . . . . . . . . . . . . . . . . . . . . 9 63 3.2.2. Hybrid Key Exchange within ServerHello . . . . . . . . 10 64 3.2.3. Hybrid Key Exchange within HelloRetryRequest . . . . . 10 65 3.2.4. Hybrid extension . . . . . . . . . . . . . . . . . . . 10 66 3.2.5. Generating the shared secret . . . . . . . . . . . . . 11 67 4. Specific information for Quantum-Safe Scheme . . . . . . . . . 11 68 4.1. NTRUEncrypt . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.2. LWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3. HFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4. McEliece/McBits . . . . . . . . . . . . . . . . . . . . . 12 72 4.5. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 12 73 5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Alternative Designs . . . . . . . . . . . . . . . . . . . . . . 14 75 6.1. Smart encoding of hybrid groups . . . . . . . . . . . . . 15 76 6.2. No usage of "supported_groups" . . . . . . . . . . . . . . 15 77 6.3. No usage of "supported_groups", encoding supported 78 hybrid groups in "key_share" . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7.1. Security, Authenticity and Forward Secrecy . . . . . . . . 16 81 7.2. Quantum Security and Quantum Forward Secrecy . . . . . . . 16 82 7.3. Quantum Authenticity . . . . . . . . . . . . . . . . . . . 17 83 8. Compatibility with TLS 1.2 and earlier version . . . . . . . . 17 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 11.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 94 1. Introduction 96 Quantum computers pose a significant threat to modern cryptography. 97 The two most widely adopted public key cryptosystems, namely, RSA 98 [PKCS1] and Elliptic Curve Cryptography (ECC) [SECG], will be 99 trivially breakable by sufficiently large general purpose quantum 100 computers. RSA is adopted in TLS from Version 1.0 to TLS Version 1.2 101 [RFC2246], [RFC4346], [RFC5246]. ECC is enabled in RFC 4492 102 [RFC4492] and adopted in TLS version 1.2 [RFC5246] and version 1.3 103 [TLS1.3]. 105 There exist several quantum-safe cryptosystems, such as the 106 NTRUEncrypt cryptosystem [EESS1], that deliver similar performance, 107 yet are conjectured to be robust against quantum computers, but these 108 are not adopted as widely as RSA or ECC and are not supported within 109 TLS 1.2 or 1.3. 111 This document describes a modular design that allows one or several 112 quantum-safe cryptosystems to be adopted in the handshake protocol of 113 TLS Version 1.3 [TLS1.3]. It uses a hybrid approach that allows the 114 combination of a non-quantum-safe but widely accepted "classical" key 115 exchange and a quantum-safe key exchange, or indeed the combination 116 of any number greater than one of key exchange mechanisms with any 117 property. The modular design provides quantum-safe features to TLS 118 1.3 and allows the flexibility to create a migration path towards 119 improved quantum-safe encryption schemes as they become available. 121 The remainder of this document is organized as follows. Section 2 122 describes the design criteria that have driven the design presented 123 in this document. Section 3 specifies the modular design of quantum- 124 safe handshake for TLS 1.3. Section 4 provides specific information 125 for quantum-safe encryption schemes. Section 5 discusses the 126 rationale of our design and some potential modifications. Section 6 127 lists some alternative designs to solve this problem that were 128 considered and rejected. Section 7 gives security considerations. 129 Section 8 discusses compatibility with other versions of TLS. 130 Section 9 describes IANA considerations for the name spaces created 131 by this document. Section 10 gives acknowledgements. 133 This is followed by the lists of normative and informative references 134 cited in this document, the authors' contact information, and 135 statements on intellectual property rights and copyrights. 137 Implementation of this specification requires familiarity with TLS 138 [RFC2246], [RFC4346], [RFC5246], [TLS1.3], TLS extensions [RFC4366], 139 and knowledge of the corresponding quantum-safe cryptosystem. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 Well-known abbreviations and acronyms can be found at RFC Editor 149 Abbreviations List [REAL]. 151 2. Design Criteria 153 The design of the proposed quantum-safe hybrid TLS 1.3 protocol is 154 driven by the following criteria: 156 1) Need for quantum-safe cryptography in TLS. Quantum computers 157 might become feasible in the next 5-10 years. If current Internet 158 communications are monitored and recorded today (D), the 159 communications could be decrypted as soon as a quantum-computer is 160 available (e.g., year Q) if key negotiation only relies on non 161 quantum-safe primitives. This is a high threat for any information 162 that must remain confidential for long period of time T > Q-D. The 163 need is obvious if we assume that Q is 2040, D is 2020, and T is 30 164 years. Such a value of T is typical in classified or healthcare 165 data. 167 2) Hybrid. Currently, there does not exist a quantum-safe key 168 exchange that is trusted at the level that ECDH is trusted against 169 conventional (non-quantum) adversaries. A hybrid approach allows 170 introducing promising quantum-safe candidates next to well- 171 established primitives. 173 3) Aligned with TLS 1.3 features such as 0-RTT. The protocol 174 operation should not affect TLS 1.3 features such as the 0-RTT 175 feature. In particular, a 0-RTT handshake should be feasible in a 176 hybrid quantum-safe TLS 1.3 design. 178 4) Limit amount of exchanged data. The protocol design should be 179 such that the amount of exchanged data, such as public-keys, is 180 kept as limited as possible even if multiple public-keys are needed 181 to be exchanged. 183 5) Future proof. Any cryptographic algorithm has the potential to 184 be broken in the future by currently unknown or impractical 185 attacks: quantum computers are merely the most concrete example of 186 this. The design does not categorize algorithms as "quantum-safe" 187 or "non quantum-safe" and does not create assumptions about the 188 properties of the algorithms, meaning that if algorithms with 189 different properties become necessary in future, this framework can 190 be used unchanged to facilitate migration to those algorithms. 192 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 194 6) Identification of hybrid algorithms. The usage of a hybrid 195 approach in which each hybrid combination of several classical and 196 quantum-safe algorithms leads to a different group identifier can 197 mean an exponential growth of identifiers and lack of 198 interoperability. Using complex hybrid schemes can also make the 199 TLS state machine complex. Thus, the design should seek an 200 approach in which hybrid algorithms can be efficiently identified. 202 7) Limited amount of changes to TLS 1.3. A key goal is to limit 203 the number of changes in TLS 1.3 when enabling a quantum-safe 204 handshake. This ensures easier and faster adoption. 206 8) Localized changes. Another key requirement is that changes to 207 the protocol are limited in scope, in particular, limiting changes 208 in the exchanged messages and in the state machine, so that they 209 can be easily implemented. 211 9) Deterministic operation. This requirement means that the hybrid 212 quantum-safe exchange, and thus, the computed key, will be based on 213 algorithms that both client and server wish to support. 215 10) Backwards compatibility and interoperability. This is a 216 fundamental requirement to ensure that hybrid quantum-safe TLS 1.3 217 and a non-quantum-safe TLS 1.3 implementations are interoperable. 219 11) FIPS compliancy. TLS is widely used in Federal Information 220 Systems and FIPS certification is an important feature. However, 221 algorithms that are believed to be quantum-safe are not FIPS 222 complaint yet. Still, the goal is that the overall hybrid quantum- 223 safe TLS 1.3 design can be FIPS compliant. 225 3. Modular design for quantum-safe key exchange 227 This document introduces a hybrid and modular approach to including 228 new quantum-safe key exchange algorithms within TLS 1.3, while 229 maintaining the assurance that comes from the use of already 230 established cipher suites. It allows the TLS premaster secret to be 231 agreed using both an established classical DH key exchange and a 232 quantum-safe key exchange mechanism. 234 The general design is to reuse the existing handshake design for DHE 235 and ECDHE groups, treating the quantum-safe key exchanges as 236 additional (EC)DH groups as much as possible. In addition, the 237 design provides for the ability to negotiate several key exchanges at 238 the same time (which could include both a classical (EC)DH group, and 239 a quantum-safe key exchange) and then combine the outputs of the key 240 exchanges through a single KDF; in this mode, the negotiated keys are 241 secure as long as at least one of the negotiated key exchanges are 243 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 245 secure. 247 With this proposal, the TLS negotiation is essentially unchanged; the 248 client issues an initial key exchange, which includes a list of 249 supported groups and key shares for share material corresponding to 0 250 or more of the indicated supported groups. The server either selects 251 one of the groups listed with a key share (and responds with its own 252 key share), or it selects one of the groups listed as supported, and 253 issues a retry request listed the selected group. 255 The extension here is that the groups listed are not confined to be 256 only DH or ECDH groups; we also allow them to be either another key 257 exchange, or an indication of a hybrid group, that is, a combination 258 of multiple specified key exchanges. The design puts no constraints 259 on what groups may be included in the combination, except that each 260 group appears no more than once, so the combination may, for example, 261 be a single ECDH group and a single quantum-safe key exchange, or a 262 combination of more than one quantum-safe key exchange, or some other 263 combination type. For any hybrid group (that is, a logical group 264 that is formed by running multiple key exchange mechanisms in 265 parallel), the client will assign the named_group id and its 266 definition. Each individual key exchange mechanism has a defined key 267 share format; this proposal also defines a format for key shares for 268 the hybrid groups, designed so that even if two hybrid groups include 269 the same key exchange mechanism, the key share material associated 270 with that key exchange mechanism is only included in the handshake 271 once. 273 3.1. Additional Quantum-Safe Key Exchanges 275 First, we extend the NamedGroup enum (ref: [TLS1.3] section 4.2.4) to 276 include values that do not correspond to either DHE or ECDHE groups, 277 but to key exchange protocols that might not represent mathematical 278 groups at all, but possibly other key exchange mechanisms. In 279 addition, we also reserve 256 entries to allow us to encode hybrid 280 groups, as explained below. 282 An example of how this enum might be encoded might be: 284 enum { 285 /* Existing Ellipic Curve Groups (ECDHE) */ 286 secp256r1 (23), secp384r1 (24), secp521r1 (25), 287 x25519 (29), x448 (30), 289 /* Existing Finite Field Groups (DHE) */ 290 ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), 291 ffdhe6144 (259), ffdhe8192 (260), 293 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 295 /* Additional quantum-safe algorithm: 296 NTRU key exchanges */ 297 ntru_eess443 (768), ntru_eess587 (769), 298 ntru_eess743 (770), 300 /* Additional quantum-safe algorithm: 301 LWE key exchange */ 302 lwe_XXX (1024), 304 /* Additional quantum-safe algorithm: 305 Hidden Field Equation key exchange */ 306 hfe_XXX (1280), 308 /* Additional quantum-safe algorithm: 309 McEliece-based key exchange */ 310 mcbits_XXX (1536), 312 /* Additional quantum-safe algorithm: 313 other quantum-safe algorithm*/ 315 /* New Code points reserved for 'Hybrid Key Exchanges' */ 316 hybrid_marker (0xfd00..0xfdff) 318 /* Existing Reserved Code Points */ 319 ffdhe_private_use (0x01fc..0x01ff), 320 ecdhe_private_use (0xfe00..0xfeff), 321 (0xffff) 322 } NamedGroup; 324 Note that the enum values given for the new groups are for 325 illustration only; the actual values would be needed to be assigned 326 by IANA. 328 In the above enum, we see new NamedGroups marked as "additional 329 quantum-safe" and "hybrid key exchange". 331 The NamedGroups marked as "additional quantum-safe" operate just 332 like the (EC)DHE groups; the client generates a KeyShareEntry (which 333 consists of the NamedGroup along with a key_exchange value; the 334 server responds with a KeyShareEntry (which, again, consists of a 335 NamedGroup along with a key_exchange value), and then both sides 336 generate a shared secret (which the TLS 1.3 draft calls the (EC)DHE 337 shared secret). These KeyShareEntries could contain a Diffie- 338 Hellman-like public value, or the client entry could contain a public 339 key and the server entry could contain a secret value encrypted with 340 that public key; the model accommodates both. 342 For each such additional quantum-safe key exchange, the following 344 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 346 will need to be specified: 348 - The format of the client key_exchange data 349 - The format of the server key_exchange data 350 - The format of the generated shared secret 352 Section 4 in this document provides links for such specifications. 354 The NamedGroups marked as "hybrid key exchange" in the above enum are 355 described in the following subsection. 357 3.2. Hybrid Key Exchanges 359 A "hybrid key exchange" is a key exchange that uses several "atomic" 360 key exchange methods in parallel (and whose resulting shared secret 361 depends on the shared secrets of each of the methods). The reasoning 362 behind this hybrid key exchange is that, in a post-quantum world, 363 there might be no single key exchange mechanism we are certain is 364 safe, and so we rely on several (and so remain secure as long as one 365 of the methods we use is secure). An example of such a hybrid key 366 exchange would be "Curve25519, in parallel with NTRU". 368 A hybrid key exchange can be formed by 2 to 10 distinct base key 369 exchange mechanisms, and are negotiated as a unit; for example, if 370 the client sends supported_groups and KeyShare that includes the 371 hybrid key exchange "Curve25519+NTRU", then the server either accepts 372 that in entirety, or rejects it; it cannot accept "Curve25519 only" 373 (unless, of course, that key exchange was listed by itself elsewhere 374 in the key share). 376 The following sections list how hybrid key exchange are represented 377 within the protocol. 379 3.2.1. Hybrid Key Exchange within ClientHello 381 To indicate support for hybrid key exchange, the client includes an 382 indication in its supported_groups extension. To enable a handshake 383 using hybrid key exchange, the client provides appropriate key share 384 material in its key_share extension. This section describes both 385 extensions. 387 3.2.1.1. Hybrid Key Exchange within the supported_groups extension 389 The client lists support for hybrid groups within the 390 supported_groups extension. To do so, it includes the hybrid group 391 id (hybrid_marker+i), with that hybrid marker being defined within 392 the hybrid extension (see section 3.2.5). 394 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 396 If the server sees such a hybrid group id within the received 397 supported_groups, it looks up the definition of that group within the 398 hybrid extension. 400 3.2.1.1. Hybrid Key Exchange within the key_share extension 402 The client hello key share contains a vector of KeyShareEntry 403 elements (which corresponds to the various key exchanges the client 404 proposes). 406 The base structure of a KeyShareEntry that represents a hybrid key 407 exchange is similar, namely: 409 struct { 410 NamedGroup hybrid_group_id; 411 KeyShareEntry key_exchange<1..2^16-1> 412 } KeyShareEntry; 414 hybrid_group_id is the hybrid group id, which is a value 415 hybrid_marker+i (for i between 0 and 255) 417 key_exchange is the list of key share entries for the groups that 418 make up this hybrid group 420 The set of key exchange mechanisms denoted by such a KeyShareEntry 421 will consist of all the key exchange mechanisms listed within the 422 key_exchange array. 424 In addition, the hybrid group id listed must be defined within the 425 hybrid extension given in the client hello message (see section 426 3.2.5), and the named groups listed in that extension must be the 427 same groups in the same order as in the key share entry. 429 Note that the variable length type key_exchange starts with the same 430 2 byte length field as the variable length opaque type in a standard 431 KeyShareEntry, hence an implementation that does not understand 432 hybrid key shares will still parse these entries (in the sense of 433 knowing that that is a key exchange mechanism it does not 434 understand), and ignore them without error. 436 In addition, the share for each individual group is listed in the 437 same format as the KeyShareEntry for that group; it is anticipated 438 that an implementation may reuse the same parsing logic for both 439 individual groups and members of a hybrid group. 441 Note that the same key exchange mechanism SHALL NOT be listed twice 443 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 445 within a hybrid key share entry. Similarly, hybrid key exchange SHALL 446 NOT be listed as a member of a hybrid key exchange. 448 To allow the client to propose the list "[Curve25519 + NTRU] or [P256 449 + NTRU]" without having to list the NTRU key share multiple times, we 450 allow the following extension to the KeyShareEntry fields within the 451 hybrid key exchange: if the key_exchange entry is listed as 0 length, 452 then the actual key_exchange data for that named group appears 453 elsewhere within the client hello key share (and the server will need 454 to search for that key share with a nonzero length). Note that the 455 server might need to search past the current position in the key 456 share (for example, if the client proposes "[Curve25519 + NTRU] or 457 Curve25519", with that priority order; as Curve25519 by itself has 458 lower priority, it occurs after the hybrid key exchange. 460 3.2.2. Hybrid Key Exchange within ServerHello 462 The server hello key share contains a single KeyShareEntry structure 463 (which is the response to the key exchange that the server accepts); 464 it uses the same format that is listed in section 3.2.1. 466 The hybrid_group_id that the server lists within the KeyShareEntry is 467 the value that the client originally designated. 469 3.2.3. Hybrid Key Exchange within HelloRetryRequest 471 If a server issues a HelloRetryRequest, and it selects a hybrid 472 group, then it includes the client-defined hybrid group id in the key 473 share. The client is expected to remember the definition it gave to 474 that hybrid group. 476 3.2.4. Hybrid extension 478 When the client lists hybrid named groups within its supported_groups 479 extension, it also includes the hybrid extension which defines which 480 named groups that together form the hybrid group. 482 This hybrid extension is an extension type of type [TBD], and may be 483 included within the ClientHello message. 485 struct { 486 NamedGroup hybrid_group_id; 487 NamedGroup components<2..10> 488 } HybridMapping; 490 hybrid_group_id This is the id of the hybrid group being defined; 491 the value given must be in the range (hybrid_marker, 492 hybrid_marker+255) 494 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 496 components This is the list of the named groups that make up this 497 hybrid group. These components MUST NOT be hybrid groups 498 themselves. 500 The "extension data" field of this extension contains a 501 HybridExtension value: 503 struct { 504 HybridMapping map<0..255>; 505 } HybridExtension; 507 map This gives the definition for all the hybrid groups listed. 508 Each entry in the map array gives the definition for one hybrid 509 group. Every hybrid group mentioned within the client hello 510 message must be listed. 512 3.2.5. Generating the shared secret 514 The entire point of the key exchange is to generate a shared secret 515 on both the client and the server that is not easily recovered by an 516 adversary who monitors the protocol messages. In the standard TLS 517 1.3 protocol, the DH or ECDH shared secret is generated, and is used 518 to derive various secret values as listed in section 7.1 of [TLS1.3], 519 with that initial shared secret being labeled as (EC)DHE. 521 When we need to derive the shared secret for a hybrid key exchange, 522 we derive each shared secret from each of the member key exchanges 523 independently, and then concatenate those shared secrets in the order 524 the key exchanges were listed in the protocol exchange; this 525 concatenated shared secret is then used in the standard TLS 1.3 526 secret derivation process as the input labeled (EC)DHE. 528 4. Specific information for Quantum-Safe Scheme 530 Selection criteria for quantum-safe cryptography to be used in this 531 TLS_QSH approach can be found at [QSHPKC]. Also see [PQCRY] for 532 initial recommendations of quantum-safe cryptography from EU's 533 PQCRYPTO project. 535 4.1. NTRUEncrypt 537 NTRUEncrypt parameter sets are identified by the values ntru_eess443 538 (0x0101), ntru_eess587 (0x0102), ntru_eess743 (0x0103) assigned in 539 this document (pending approval by IANA). 541 For each of these parameter sets, the public key and ciphertext are 543 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 545 Ring Elements as defined in [EESS1]. The encoded public key and 546 ciphertext are the result of encoding the relevant Ring Element with 547 RE2BSP as defined in [EESS1]. 549 For each parameter set the the maximum plaintext input length in 550 bytes is as follows. This is used when determining the length of the 551 client/server-generated secrets CliSi and SerSi as specified in 552 sections 3.4 and 3.5. 554 eess443 49 555 eess587 76 556 eess743 106 558 4.2. LWE 559 Encoding not defined in this document. 561 4.3. HFE 562 Encoding not defined in this document. 564 4.4. McEliece/McBits 565 Encoding not defined in this document. 567 4.5. Pre-Shared Keys 569 The identities of the exchanged Pre-Shared Keys SHALL be encoded in a 570 similar way to [TLS1.3]. 572 struct { 573 identity<0..2^16-1>; 574 } PskIdentity; 576 struct { 577 select (Handshake.msg_type) 578 { 579 case client_hello: PskIdentity identities<6..2^16-1>; 580 case server_hello: uint16 selected_identity; 581 }; 582 } PreSharedKeyExtension; 584 This struct is to be exchanged in the key_exchange array in the 585 KeyShareEntry. 587 The client and server agree on common PSKs that they can combine with 588 other generated secrets as described in Section 3.2.6 of this 590 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 592 document. 594 The use of PSKs in the quantum-hybrid handshake SHALL follow one of 595 the following patterns 597 1) (The PSK is not intended to provide quantum-resistance) The PSK 598 SHALL be used in conjunction with another key exchange algorithm 599 that is believed to be quantum-safe. In this case, the PSK SHALL 600 conform to the security requirements in [TLS1.3]. 602 2) (The PSK is intended to provide quantum-resistance) The PSK 603 SHALL have a key length of at least 256 bits and SHALL NOT have 604 been computed by means of a classical key exchange. 606 5. Design Rationale 608 The design of the protocol described in Section 3 follows criteria 609 presented in Section 2. 611 1) It allows introducing quantum-safe key exchange in TLS 1.3. 613 2) It introduces a hybrid and modular quantum-safe exchange to 614 allow multiple key exchange mechanisms in parallel (and arrange 615 things such that we are secure if any of these key exchange 616 mechanisms remain unbroken). 618 3) It further supports the features of TLS 1.3. In particular, it 619 still supports 0-RTT handshake. 621 4) It does not add an excessive amount of payload data to the TLS 622 negotiation by considering smart econdings. For instance, in the 623 initial ClientHello keyshare; the obvious encoding of "[x25519 AND 624 NTRU] or [secp256r1 AND NTRU]" would require the NTRU keyshare to 625 be repeated within the record; if a number of such key shares were 626 used, this could add up to a considerable amount of overhead. To 627 avoid this, it was decided to allow the client to include the 628 actual keyshare once (and have all other occurances use the length 629 0 keyshare, as stated in 2.1.1. This does add complexity to the 630 server parser code; however we believe that the savings in 631 bandwidth is worth it. 633 5) The proposed design is future proof since it reuses the current 634 TLS 1.3 design without adding complexity. In fact, one of the 635 things we were able to take the advantage of was the NamedGroup 636 negotiation logic within TLS 1.3. It was originally designed so 637 that the client could open negotiations with "here's my key shares 638 for secp256r1 and x25519, and I also support x488 and ffdhe2048"; 639 we extend that so that it can also say "where's my key shares for 641 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 643 [x25519 AND NTRU] and x25519 (alone), and I also support "[x25519 644 and rLWE]" 646 6) The described protocol allows for a simple but efficient 647 Identification of hybrid algorithms. We note that it would have 648 been plausible to allow the client to try to encode support for 649 "any combination of [secp256r1 OR x25519] AND [NTRU OR rLWE] AND 650 [SIDH OR McBits]". However, it was unclear how to do so without 651 adding a significant amount of complexity to the server parser, and 652 with a description that was understandable. Because of this, it 653 was decided to stay with a simpler list. 655 7 and 8) It minimizes complexity by introducing limited amount of 656 changes in the protocol logic. We only require an additional 657 extension header used to exchange the supported hybrid groups. 659 9) It ensures that the hybrid algorithm selected will be based on 660 algorithms that both the client and the server support. 662 10) It ensures interoperability between implementations that 663 implement this draft and those that do not; between any two such 664 systems, both sides will either agree on a key exchange that is 665 mutually acceptable, or correctly realize that no such mechanism 666 exists. 668 11) Being FIPS compliant is an important requirement. By allowing 669 a hybrid group to consist of a FIPS approved key exchange (such as 670 secp256r1) and a quantum-safe group, and generating the session 671 keys based on the FIPS approved group (and other data), this 672 overall approach can be FIPS compliant. 674 Further remarks: 676 We limit the size of a hybrid group to a maximum of 10 simple 677 groups. We do this to allow an implementation that needs an upper 678 bound to have one (and we consider it unlikely that anyone would 679 actually need 11 distinct key exchanges). 681 The current [TLS1.3] draft specifies the usage of the 682 'HelloRetryRequest' message allowing the server to propose groups 683 that had not been initially proposed by the client. This 684 functionality has not been described in this Internet Draft yet, 685 but could be realized by allowing the server to add its own server 686 hybrid extension, and list the hybrid group it wants in it. 688 6. Alternative Designs 690 Several designs for a hybrid TLS handshake exist and have been 692 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 694 considered during the preparation of this draft. The design 695 presented above in Section 3 is the preferred option for a hybrid TLS 696 handshake. This section describes alternative designs, including 697 their pros and also the reasons why they were not considered as the 698 preferred solution. 700 6.1. Smart encoding of hybrid groups 702 TLS 1.3 defines the usage of the supported_groups extension header to 703 exchange the groups supported by client and server. A hybrid group 704 includes multiple groups. Thus, it is required to specify which of 705 the groups belong to a hybrid group while still fitting the current 706 TLS 1.3 specification so that existing implementations process the 707 message properly. This can be done by using an encoding in which a 708 hybrid group is encoded over a word array in which all of the words 709 start with the hybrid marker 0xfd concatenated with a byte that 710 includes the useful information about the hybrid group. Since all 711 words start with 0xfd, then an implementation non-aware of hybrid 712 groups will discard those unknown groups. In the word array, the 713 second byte of the first word contains the number of words used to 714 encode the information of the hybrid group. The second byte of the 715 second word contains the identifier of the hybrid group. Afterwards 716 each pair of words is used to encode a group contained in the hybrid 717 group. With this smart encoding, the groups of a hybrid group can be 718 encoded in 2*(1+N) words, where N is the number of groups contained 719 in the hybrid group. 721 The advantage of this design is that no additional extension headers 722 are required. The drawback of the design is that the description of 723 the encoding is relatively complex, and this is the main reason why 724 it was not further considered. 726 6.2. No usage of "supported_groups" 728 TLS 1.3 defines two main extensions, "key_share" and 729 "supported_group". The main design proposal in Section 3 transmits 730 the supported hybrid groups by means of an additional extensions 731 header. The alternative design presented in Section 6.1 describes an 732 smart encoding for these hybrid groups so that additional extension 733 headers are not required. The alternative presented in this section 734 just uses what is available. 736 In particular, a simple approach would enforce that hybrid clients 737 can only use the "key_share" extension, but not the "supported_group" 738 extension. In this case, the only situation that can be encountered 739 that might create some issue is when a client supporting hybrid 740 groups contacts a server that is not aware of them and the server 741 replies with the "supported_groups" extension. However, in this 743 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 745 case, the client can just ignore it and all the classical groups in 746 it. This proposal has the benefit that no changes are required (no 747 additional encoding or no additional extension headers), but it has 748 the limitation that client and server can only communicate via the 749 "key_share" extension that can be relatively bulky, in particular, if 750 we have hybrid groups. This is the main reason for not considering 751 this proposal. 753 6.3. No usage of "supported_groups", encoding supported hybrid groups 754 in "key_share" 756 This last proposal builds on the previous one (Section 6.2) in such a 757 way that hybrid clients and servers encode supported hybrid groups. 759 The only situation that this configuration can create a problem is 760 when a hybrid client contacts with a classic server and the hybrid 761 client transmits the "key_share" encoding its hybrid groups by not 762 including the corresponding public keys. The server will not 763 understand this since this is a forbidden configuration and thus it 764 will terminate the connection. This unexpected behavior in TLS 1.3. 765 is the main reason for not considering this proposal further, even if 766 this outcome is very likely to be the outcome desired by the client 767 since a hybrid client is not interested in establishing a non-hybrid 768 connection. 770 7. Security Considerations 772 7.1. Security, Authenticity and Forward Secrecy 774 Security, authenticity and forward secrecy against classical 775 computers are inherent from classical handshake mechanism. 777 7.2. Quantum Security and Quantum Forward Secrecy 779 The proposed handshake mechanism provides quantum security and 780 quantum forward secrecy. 782 Quantum resistant feature of QSHSchemes ensures a quantum attacker 783 will not learn QSH keying material S. A quantum attacker may learn 784 classic handshake information. Given an input X, the leftover hash 785 lemma [LHL] ensures that one can extract Y bits that are almost 786 uniformly distributed, where Y is asymptotic to the min-entropy of X. 787 An adversary who has some partial knowledge about X, will have almost 788 no knowledge about Y. This guarantees the attacker will not learn 789 the final premaster secret so long as S has enough entropy and 790 remains secret. This also guarantees the premaster secret is secure 791 even if the client's and/or the server's long term keys are 792 compromised. 794 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 796 7.3. Quantum Authenticity 798 The proposed approach relies on the classical cipher suite for 799 authenticity. Thus, an attacker with quantum computing capability 800 will be able to break the authenticity. 802 8. Compatibility with TLS 1.2 and earlier version 804 Compatibility with TLS 1.2 and earlier version can be found in 805 [QSH12]. 807 9. IANA Considerations 809 This document adds new entries to the NamedGroup name space for use 810 with the TLS protocol. 812 10. Acknowledgements 814 Funding for the RFC Editor function is provided by the IETF 815 Administrative Support Activity (IASA). 817 We wish to thank Douglas Stebila, John Schanck for helpful 818 discussions. 820 11. References 822 11.1. Normative References 824 [EESS1] Consortium for Efficient Embedded Security, "Efficient 825 Embedded Security standards (EESS) #1", March 2015, 826 . 829 [FIPS180] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 831 [FIPS186] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 833 [H2020] Lange, T., "PQCRYPTO project in the EU", April, 2015. 834 836 [HOF15] Hoffstein, J., Pipher, J., Schanck, J., Silverman, J., 837 Whyte, W., and Zhang, Z., "Choosing Parameters for 838 NTRUEncrypt", 2015. 840 [LIN11] Lindner, R., and Peikert, C., "Better Key Sizes (and 841 Attacks) for LWE-Based Encryption", 2011. 843 [LHL] Impagliazzo, R., Levin, L., and Luby, M., "Pseudo-random 845 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 847 generation from one-way functions", 1989. 849 [MCBIT] Bernstein, D., Chou, T., and Schwabe, P., "McBits: Fast 850 Constant-Time Code- Based Cryptography", 2013. 852 [MCELI] McEliece, R., "A Public-Key Cryptosystem Based On 853 Algebraic Coding Theory", 1978. 855 [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 856 1.5", PKCS 1, November 1993 858 [PQCRY] PQCRYPTO, "Initial recommendations of long-term secure 859 post-quantum systems". 860 862 [QSH12] Schanck, J., Whyte, W., and Zhang, Z., "Quantum-Safe 863 Hybrid (QSH) Ciphersuite for Transport Layer Security 864 (TLS) version 1.2", draft-whyte-qsh-tls12-00, July 2015. 866 [QSHPKC] Schanck, J., Whyte, W., and Zhang, Z., "Criteria for 867 selection of public-key cryptographic algorithms for 868 quantum-safe hybrid cryptography", draft-whyte-select-pkc- 869 qsh-00.txt, Sep 2015. 871 [REAL] "RFC Editor Abbreviations List", September 2013, 872 . 875 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 876 Requirement Levels", RFC 2119, March 1997. 878 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 879 RFC 2246, January 1999. 881 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 882 IANA Considerations Section in RFCs", RFC 2434, October 883 1998. 885 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 886 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 888 [RFC4366] Blake-Wilson, S., Nysrom, M., Hopwood, D., Mikkelsen, J., 889 and T. Wright, "Transport Layer Security (TLS) 890 Extensions", RFC 4366, April 2006. 892 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 893 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 894 for Transport Layer Security (TLS)", RFC 4492, May 2006. 896 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2017-01-23 898 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 899 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 901 [TLS1.3] E. Rescorla, "The Transport Layer Security (TLS) Protocol 902 Version 1.3", draft-ietf-tls-tls13-05, March 2015. 904 11.2. Informative References 906 [RFC5990] Randall, J., Kaliski, B., Brainard, J. and Turner S., "Use 907 of the RSA-KEM Key Transport Algorithm in the 908 Cryptographic Message Syntax (CMS)", RFC 5990, September 909 2010. 911 [RFC5859] Krawczyk, H., Eronen, P., "HMAC-based Extract-and-Expand 912 Key Derivation Function (HKDF)", RFC 5859, May 2010. 914 Authors' Addresses 916 Scott Fluhrer 917 Cisco Systems 918 sfluhrer@cisco.com 920 William Whyte 921 Security Innovation, US 922 wwhyte@securityinnovation.com 924 Zhenfei Zhang 925 Security Innovation, US 926 zzhang@securityinnovation.com 928 Oscar Garcia-Morchon 929 Philips 930 oscar.garcia-morchon@philips.com 932 Copyright Notice 934 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 935 2: Copyright (c) 2015 IETF Trust and the persons identified as the 936 document authors. All rights reserved. 938 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii), 939 paragraph 3: This document is subject to BCP 78 and the IETF Trust's 940 Legal Provisions Relating to IETF Documents 941 (http://trustee.ietf.org/license-info) in effect on the date of 942 publication of this document. Please review these documents 943 carefully, as they describe your rights and restrictions with respect 944 to this document.