idnits 2.17.1 draft-whyte-qsh-tls12-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 377 has weird spacing: '...ReqType ser...' == Line 383 has weird spacing: '... int min...' == Line 384 has weird spacing: '... int max...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: serPKReq.min MUST not be greater than serPKReq.max. Either field MUST not be greater than the maximum number that is supported by the protocol (this may due to the size of the extensions and size of the encoded public keys, etc). If the serPKReq.min equal serPKReq.max, the client requires specifically serPKReq.min number of public keys. When both field are zero, the client do not wish to receive any public keys. When 0 <= serPKReq.min < serPKReq.max, the client lets the server to decide the number of public keys (between serPKReq.min and serPKReq.max). -- The document date (21 July 2015) is 3200 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SECG' is mentioned on line 76, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 143, but not defined == Missing Reference: 'CliPKList' is mentioned on line 172, but not defined == Missing Reference: 'SerPKList' is mentioned on line 174, but not defined == Missing Reference: 'SerCipherList' is mentioned on line 176, but not defined == Missing Reference: 'CliCipherList' is mentioned on line 178, but not defined == Missing Reference: 'IANA' is mentioned on line 297, but not defined == Unused Reference: 'FIPS180' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'FIPS186' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC5990' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'RFC5859' is defined on line 771, but no explicit reference was found in the text ** 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 (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. M. Schanck 3 Intended Status: Experimental Security Innovation & U. Waterloo 4 Expires: 21 Jan 2016 W. Whyte 5 Security Innovation 6 Z. Zhang 7 Security Innovation 8 21 July 2015 10 Quantum-Safe Hybrid (QSH) Ciphersuite for 11 Transport Layer Security (TLS) version 1.2 12 draft-whyte-qsh-tls12-00.txt 14 Abstract 16 This document describes the Quantum-Safe Hybrid ciphersuite, a new 17 cipher suite providing modular design for quantum-safe cryptography 18 to be adopted in the handshake for the Transport Layer Security (TLS) 19 protocol version 1.2. In particular, it specifies the use of the 20 NTRUEncrypt encryption scheme in a TLS handshake. 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 21 Jan, 2016. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2. Modular design for quantum-safe hybrid handshake . . . . . . . 5 49 3. Data Structures and Computations . . . . . . . . . . . . . . . 7 50 3.1. Data structures for Quantum-safe Crypto Schemes . . . . . 8 51 3.2. Client Hello Extensions . . . . . . . . . . . . . . . . . 9 52 3.3. Server Hello Extension . . . . . . . . . . . . . . . . . . 11 53 3.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 12 54 3.5. Client Key Exchange . . . . . . . . . . . . . . . . . . . 14 55 4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 15 56 5. Specific information for Quantum Safe Scheme . . . . . . . . . 15 57 5.1 NTRUEncrypt . . . . . . . . . . . . . . . . . . . . . . . 15 58 5.2. LWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 59 5.3. HFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 61 6.1. Security, Authenticity and Forward Secrecy . . . . . . . . 16 62 6.2. Quantum Security and Quantum Forward Secrecy . . . . . . . 16 63 6.3. Quantum Authenticity . . . . . . . . . . . . . . . . . . . 16 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 70 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 1. Introduction 74 Quantum computers pose a significant threat to modern cryptography. 75 Two most widely adopted public key cryptosystems, namely, RSA [PKCS1] 76 and Elliptic Curve Cryptography (ECC) [SECG], will be broken by 77 general purpose quantum computers. RSA is adopted in TLS from 78 Version 1.0 and to TLS Version 1.2 [RFC2246], [RFC4346], [RFC5246], 79 [TLS1.3]. ECC is enabled in RFC 4492 [RFC4492] and adopted in TLS 80 version 1.2 [RFC5246]. On the other hand, there exist several 81 quantum-safe cryptosystems, such as the NTRUEncrypt cryptosystem 82 [EESS1], that deliver similar performance, yet are conjectured to be 83 robust against quantum computers. 85 This document describes a modular design that allows one or many 86 quantum-safe cryptosystems to be adopted in the handshake protocol, 87 applicable to TLS Version 1.0 to Version 1.3 [RFC2246], [RFC4346], 88 [RFC5246], [TLS1.3]. It uses a hybrid approach that combines a 89 classical handshake mechanism with key encapsulation mechanisms 90 instantiated with quantum-safe encryption schemes. The modular 91 design provides quantum-safe features to TLS with an introduction of 92 only one new cipher suite. Yet, it allows the flexibility to include 93 new and advanced quantum-safe encryption schemes at present and in 94 the future. 96 The remainder of this document is organized as follows. Section 2 97 provides an overview of the modular design of quantum-safe handshake 98 for TLS. Section 3 specifies various data structures needed for a 99 quantum safe handshake, their encoding in TLS messages, and the 100 processing of those messages. Section 4 defines new TLS_QSH cipher 101 suites. Section 5 provides specific information for quantum safe 102 encryption schemes. Section 6 discusses security considerations. 103 Section 7 describes IANA considerations for the name spaces created 104 by this document. Section 8 gives acknowledgements. 106 This is followed by the lists of normative and informative references 107 cited in this document, the authors' contact information, and 108 statements on intellectual property rights and copyrights. 110 Implementation of this specification requires familiarity with TLS 111 [RFC2246], [RFC4346], [RFC5246], [TLS1.3], TLS extensions [RFC4366], 112 and knowledge of the corresponding quantum-safe cryptosystem. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 Well-known abbreviations and acronyms can be found at RFC Editor 119 Abbreviations List [REAL]. 121 2. Modular design for quantum-safe hybrid handshake 123 This document introduces a modular approach to including new quantum- 124 safe key exchange algorithms within TLS, while maintaining the 125 assurance that comes from the use of already established cipher 126 suites. It allows the TLS premaster secret to be agreed using both 127 an established classical cipher suite and a quantum-safe key 128 encapsulation mechanism. 130 Client Server 131 ------ ------ 132 ClientHello --------> 133 ServerHello 134 Certificate* 135 ServerKeyExchange* 136 CertificateRequest*+ 137 <-------- ServerHelloDone 138 Certificate*+ 139 ClientKeyExchange 140 CertificateVerify*+ 141 [ChangeCipherSpec] 142 Finished --------> 143 [ChangeCipherSpec] 144 <-------- Finished 146 Application Data <-------> Application Data 148 * message is not sent under some conditions 149 + message is not sent unless client authentication 150 is desired 152 Figure 1: Message flow in a full TLS 1.2 handshake 154 Figure 1 shows all messages involved in the TLS key establishment 155 protocol (aka full handshake). The addition of quantum-safe 156 cryptography has direct impact only on the ClientHello, the 157 ServerHello, the ServerKeyExchange, and the ClientKeyExchange. In 158 the rest of this document, we describe each quantum-safe key exchange 159 data structure in greater detail in terms of the content and 160 processing of these messages. 162 The authentication is provided by classical cryptography. The 163 introduction of quantum-safe encryption schemes delivers forward 164 secrecy against quantum attackers. The additional cryptographic data 165 exchanged between the client and the server is shown in Figure 2. 167 Client Server 168 ------ ------ 169 ClientHelloExtension 170 (SerPKReq| 171 QSHSchemeIDList| 172 [CliPKList]) --------> 173 ServerHelloExtension 174 ([SerPKList]) 175 ServerKeyExchange 176 <-------- ([SerCipherList]) 177 ClientKeyExchange 178 ([CliCipherList]) --------> 180 ClassicS|SerS|CliS <-------> ClassicS|SerS|CliS 182 [struct]: struct is optional 184 Figure 2: Additional cryptographic data in handshake 186 As usual, the ClientHello message includes the list of classical 187 cipher suites the client wishes to negotiate (e.g., 188 TLS_ECDH_ECDSA_WITH_NULL_SHA), as well as a new cipher suite 189 identifier TLS_QSH (short for TLS with Quantum Safe Hybrid 190 handshake). This new identifier SHOULD appear first in the list of 191 cipher suites. 193 The ClientHelloExtension field MAY have three additional fields: 194 o SerPKReq: a request for server's public key; also indicates the 195 number of server's public keys the client wishes to 196 receive 197 o QSHSchemeIDList: 198 a list of distinct QSHSchemeIDs from the client, 199 each ID represents a quantum safe encryption 200 scheme/parameter set supported by the client 201 o CliPKList: a list of client's public keys [CPK1]|[CPK2]|... 202 each corresponding to a distinct QSHScheme in 203 QSHSchemeIDList 205 Note: The client does not need to provide public keys for all 206 QSSchemes from the list. The client indicates that it does not wish 207 to contribute a public key for certain QSScheme by omitting the 208 corresponding public key field. 210 The ServerHelloExtension field MAY have one additional field: 211 o SerPKList: a list of Server's public keys [SPK1]|[SPK2]|... 212 each corresponding to a QSHScheme in 213 QSHSchemeIDList 215 Note: SerPKList is a list of public key structures QSHPK. For each 216 structure, there is a QSHSchemeID field identifying the corresponding 217 encryption scheme. This QSHSchemeID MUST exist in QSHSchemeIDList. 219 The ServerKeyExchange message MAY contain an additional list of 220 ciphertexts: 221 o SerCipherList: 222 a list of ciphertexts 223 [Encrypt_CPK1(SerS1)]|[Encrypt_CPK2(SerS2)]|... 224 where the server-contributed secret keying material 225 is SerS = SerS1|SerS2|..., and CPKi is selected from 226 CliPKList. 227 At least one of SerPKList and SerCipherList MUST have at least one 228 entry. 230 Additionally, the ServerKeyExchange contains an indication of the 231 classical cipher suite selected, and the ServerKeyExchange material 232 appropriate to that cipher suite. 234 If SerPKList was provided, the ClientKeyExchange message MUST contain 235 an additional list of ciphertexts: 236 o CliCipherList: 237 a list of ciphertexts 238 [Encrypt_SPK1(CliS1)]|[Encrypt_SPK2(CliS2)]|... 239 where the client-contributed secret keying material 240 is CliS = CliS1|CliS2|... , and SPKi is from 241 SerPKList. 243 The client MUST use all public keys from SerPKList. 245 Additionally, the ClientKeyExchange contains the ServerKeyExchange 246 material appropriate to the selected classical cipher suite. 248 SerS and CliS cannot be both NULL. 250 The final premaster secret negotiated by the client and the server is 251 the concatenation of the classical premaster secret, SerS, and CliS 252 in that order. 253 A 48 bytes fixed length master secret is derived from the premaster 254 secret at the end of the handshake, using a pseudo random function 255 specified by the classical cipher suite (see Section 8.1. RFC 5246 256 [RFC5246]). 258 3. Data Structures and Computations 260 This section specifies the data structures and computations used by 261 TLS_QSH cipher suite specified in Sections 2. The presentation 262 language used here is the same as that used in TLS [RFC2246], 264 [RFC4346], [RFC5246]. Since this specification extends TLS, these 265 descriptions should be merged with those in the TLS specification and 266 any others that extend TLS. This means that enum types may not 267 specify all possible values, and structures with multiple formats 268 chosen with a select() clause may not indicate all possible cases. 270 3.1. Data structures for Quantum-safe Crypto Schemes 272 enum { 273 ntru_eess439 (0x0101), 274 ntru_eess593 (0x0102), 275 ntru_eess743 (0x0103), 276 reserved (0x0102..0x01FF), 277 lwe_XXX (0x0201), 278 reserved (0x0202..0x02FF), 279 hfe_XXX (0x0301), 280 reserved (0x0302..0x03FF), 281 reserved (0x0400..0xFEFF), 282 (0xFFFF) 283 } QSHSchemeID; 285 ntru_eess439, etc: Indicates parameter set to be used for the 286 NTRUEncrypt encryption scheme. The name of the parameter sets 287 defined here are those specified in [EESS1]. 289 lwe_XXX, etc: Indicates parameters for Learning With Error (LWE) 290 encryption scheme. The name of the parameters defined here are 291 not specified in this document. 293 hfe_XXX, etc: Indicates parameters for Hidden Field Equotion (HFE) 294 encryption scheme. The name of the parameters defined here are 295 not specified in this document. 297 The QSHSchemes name space is maintained by IANA [IANA]. See Section 298 6 for information on how new schemes are added. 300 The server implementation SHOULD support all of the above QSHSchemes, 301 and client implementation SHALL support at least one of them. 303 struct { 304 QSHSchemeID id, 305 opaque pubKey<1..2^16-1> 306 } QSHPK; 308 struct { 309 QSHPK keys<1..2^24-1> 310 } QSHPKList; 312 The structure of public keys exchanged by the client and the server, 313 namely, QSHPK, has two fields: QSHSchemeID specifies the 314 corresponding quantum safe encryption scheme, and an opaque encodes 315 the actual public key data following the specification of the 316 corresponding quantum safe encryption scheme. Any entity that 317 reserves a new quantum safe encryption scheme identifier MUST specify 318 how the keys and ciphertexts for that scheme are encoded. See 319 Section 5 for definitions of the encodings of the schemes specified 320 in this document. 322 The QSHPKList is a list of QSHPKs. 324 struct { 325 QSHSchemeID id, 326 opaque encryptedKey<1..2^16-1> 327 } QSHCipher; 329 struct { 330 QSHCipher encryptedKeys<1..2^24-1> 331 } QSHCipherList; 333 The structure of ciphertext exchanged by the client and the server, 334 namely QSHCipher, has two fields: QSHSchemeID specifies the 335 corresponding quantum safe encryption scheme, and an opaque encodes 336 the actual ciphertext following the specification of the 337 corresponding quantum safe encryption scheme. 339 The QSHCipherList is a list of ciphertexts. 341 3.2. Client Hello Extensions 343 This section specifies a TLS extension that can be included with the 344 ClientHello message as described in RFC 4366 [RFC4366]. 346 When these extensions are sent: 348 The extensions MUST be sent along with any ClientHello message that 349 proposes TLS_QSH cipher suites. 351 Meaning of these extensions: 353 These extensions allow a client to send a request for server's public 354 key, a list that enumerates QSHSchemeIDs for supported quantum safe 355 cryptosystems, and/or public keys corresponding to QSHSchemeIDs. 357 Note: QSHSchemeID MUST be distinct in QSHSchemeIDList. For each 358 QSHSchemeID there MUST be at most one public key CPKi. 360 Structure of the extension: 362 The general structure of TLS extensions is described in [RFC4366], 363 and this specification adds a new type to ExtensionType. 365 enum { quantum-safe-hybrid(0x18)} ExtensionType; 367 quantum-safe-hybrid (Supported TLS_QSH Extension): Indicates the list 368 of QSHSchemeIDs supported by the client. For this extension, the 369 opaque extension_data field may contain SrvPkReq, QSHSchemeIDList 370 and CliPKList. 372 struct { 373 select (CipherSuite) { 374 case TLS_QSH: 375 QSHSchemeIDList qshSchemeIDList, 376 QSHPKList cliPKList, 377 SerPkReqType serPkReq, 378 } ClientHelloExtension; 380 SerPKReqType is defined as follows: 382 struct { 383 int min, 384 int max 385 } SerPkReqType; 387 serPKReq.min MUST not be greater than serPKReq.max. Either field 388 MUST not be greater than the maximum number that is supported by the 389 protocol (this may due to the size of the extensions and size of the 390 encoded public keys, etc). If the serPKReq.min equal serPKReq.max, 391 the client requires specifically serPKReq.min number of public keys. 392 When both field are zero, the client do not wish to receive any 393 public keys. When 0 <= serPKReq.min < serPKReq.max, the client lets 394 the server to decide the number of public keys (between serPKReq.min 395 and serPKReq.max). 397 Items in qshSchemeIDList are ordered according to the client's 398 preferences (favorite choice first). 400 As an example, a client that only supports ntru_eess439 (0x0101) and 401 ntru_eess593 (0x0102) and prefers to use ntru_eess439 would encode 402 its qshSchemeIDList as follows: 404 04 01 01 01 02 406 The client MAY append a list of public keys corresponding to each 407 crypto system. If serPKReq is (0,0), the client MUST list all public 408 keys corresponding to each qshSchemeID form qshSchemeIDList. 410 00 18 | extension length | 00 04 01 01 01 02 | CliPKList length 411 | CPK1 | CPK2 | CPK3 | ... | 00 | 413 Note: the extension type value appearing in these examples is 414 tentative. 416 Actions of the sender: 418 A client that proposes TLS_QSH cipher suites in its ClientHello 419 message appends these extensions (along with any others), indicating 420 whether the client wishes the server to contribute its quantum-safe 421 public key, enumerating the supported quantum-safe crypto systems, 422 and/or the public key corresponding to each crypto system. 424 Actions of the receiver: 426 A server that receives a ClientHello with a TLS_QSH cipher suite MUST 427 check the extension field to use the client's enumerated capabilities 428 to guide its selection of an appropriate cipher suite. The TLS_QSH 429 cipher suite must be negotiated only if the server can successfully 430 complete the handshake while using the listed quantum-safe 431 cryptosystems from the client. 433 The server will carry out a classic handshake with the client using a 434 classical cipher suite (other than TLS_QSH) indicated by the client. 435 The server will also select a (list of) supported QSHScheme(s), 436 indexed by QSHSchemeID(s). If server's public key(s) is required, 437 the server will generate public/private keys corresponding to these 438 QSHSchemeIDs. 440 If a server does not understand the Extension, does not understand 441 the list of quantum-safe encryption schemes, or is unable to complete 442 the TLS_QSH handshake while restricting itself to the enumerated 443 cryptosystems, it MUST NOT negotiate the use of a TLS_QSH cipher 444 suite. Depending on what other cipher suites are proposed by the 445 client and supported by the server, this may result in a fatal 446 handshake failure alert due to the lack of common cipher suites. 448 3.3. Server Hello Extension 450 This section specifies a TLS extension that can be included with the 451 ServerHello message as described in RFC 4366 [RFC4366]. 453 When this extension is sent: 455 The extensions MUST be sent along with any ServerHello message that 456 accepts TLS_QSH cipher suites. 458 Meaning of this extension: 460 This extension allows a server to notify the client the ID(s) and 461 public key(s) for the quantum-safe encryption scheme(s) it chooses 462 from the QSHSchemeIDList. 464 Structure of this extension: 466 struct { 467 select (CipherSuite) { 468 case TLS_QSH: 469 QSHPKList serPKList 470 } ServerHelloExtension; 472 Actions of the sender: 474 The server selects a number of QSHSchemeIDs in response to a 475 ClientHelloExtension message. The selection is based on client's 476 preference and ReqSerPK field. The QSHSchemeIDs selected MUST exist 477 in the received QSHSchemeIDList. For each scheme, the server sets 478 QSHPK.id to the QSHSchemeID that it selects. If the server is 479 willing/requested to contribute its public key, the server will 480 generate a pair of public/private keys, and set QSHPK.pubKey to this 481 the public key; otherwise this field will be empty. The server form 482 the SerPKList with the list of QSHPK. 484 Note: if the server sends no public keys in the Server Hello 485 Extension, it MUST send at least one ciphertext in the EncryptedSerS 486 at the Server Key Exchange message. 488 Actions of the receiver: 490 A client that receives a ServerHello message containing an extension 491 will extract the agreed QSHSchemeIDs and the server's public keys 492 from serPKList. The client-generated secrets will be encrypted with 493 server's ephemeral public keys as described in Section 3.5. 495 3.4. Server Key Exchange 497 When this message is sent: 499 This message is sent in all implementations of this cipher suite. 501 Meaning of this message: 503 This message is used to send classical key exchange information to 504 the client. It MAY also be used to send key material (encrypted by 505 one or many of the client's public keys) to the client. 507 Structure of this message: 509 The TLS ServerKeyExchange message is extended as follows. 511 struct { 512 select (KeyExchangeAlgorithm) { 513 case TLS_QSH: 514 QSHCipherList encryptedSerS, 515 CipherSuite classical_ciphersuite, 516 ServerKeyExchange classical_exchange 517 } exchange_keys; 518 } ServerKeyExchange; 520 Actions of the sender: 522 The server sets the CipherSuite field to the classical cipher suite. 523 This MUST be one of the next preferable cipher suites other than 524 TLS_QSH that was received in the ClientHello. 526 The server sets classical_exchange to have the contents appropriate 527 for the indicated classical cipher suite. 529 If a number of client's public keys CPK1,...CPKn were received in the 530 Client Hello Extension, the server: 532 1. Selects k<=n of these public keys. 534 2. For each of the public keys CPKi, generates a secret SerSi. 535 The length in bytes of SerSi MUST be the lesser of (a) 48, the 536 length of the classical master secret, and (b) the maximum 537 plaintext input length for the corresponding encryption scheme 538 (see Section 5). 540 3. Encrypts the SerSi with PKi. 542 4. Creates a QSHCipherList structure containing the encrypted 543 secrets. 545 Note: since it is required that each of the public keys in the 546 ClientHelloExtension is for a distinct quantum-safe encryption 547 scheme, the QSHCipherList unambiguously identifies which client 548 public key corresponds to which server-generated ciphertext. 550 The server-contributed keying material is: 551 SerS = SerS1|SerS2|...|SerSk 553 Actions of the receiver: 555 The client processes the ServerKeyExchange with KeyExchangeAlgorithm 556 as in a classical handshake. If EncryptedSerS is not NULL, the 557 client decrypts each ciphertext in encryptedSerS using the client's 558 secret key identified by QSHIDs from SerPKList (received from 559 ServerHelloExtension) and obtains SerS. Otherwise, the client sets 560 SerS to NULL. 562 3.5. Client Key Exchange 564 When this message is sent: 566 This message is sent in all key exchange algorithms. 568 Meaning of the message: 570 This message is used to convey ephemeral data relating to the key 571 exchange belonging to the client (such as its ephemeral ECDH public 572 key). It is also used to send client's quantum-safe keying material 573 to the server. 575 Structure of this message: 577 The TLS ClientKeyExchange message is extended as follows. 579 struct { 580 select (KeyExchangeAlgorithm) { 581 case QSH: 582 QSHcipher encryptedCliS, 583 ClientKeyExchange classical_exchange 584 } exchange_keys; 585 } ClientKeyExchange; 587 Actions of the sender: 589 The client sets classical_exchange to have the contents appropriate 590 for the indicated classical cipher suite. 592 If a number of server's public keys SPK1,...SPKk were received in the 593 Server Hello Extension, the client: 595 1. For each of the public keys SPKi, generates a secret CliSi. 596 The length in bytes of CliSi should be the lesser of (a) 48, the 597 length of the classical master secret, and (b) the maximum 598 plaintext input length for the corresponding encryption scheme 599 (see Section 5). 601 2. Encrypts the CliSi with SPKi. 603 3. Creates a QSHCipherList structure containing the encrypted 604 secrets. 606 Note: since it is required that each of the public keys in the Client 607 Hello Extension is for a distinct quantum-safe encryption scheme, the 608 QSHCipherList unambiguously identifies which server public key 609 corresponds to which client-generated ciphertext. 611 The client-contributed keying material is: 612 CliS = CliS1|CliS2|...|CliSk. 614 The final premaster secret negotiated by the client and the server is 615 the concatenation of the classical premaster secret, SerS, and CliS 616 in that order. A 48 bytes fixed length master secret is derived from 617 the premaster secret at the end of the handshake, using a pseudo 618 random function specified by the classical cipher suite (see Section 619 8.1. RFC 5246 [RFC5246]). 621 Actions of the receiver: 623 The server processes the ClientKeyExchange with KeyExchangeAlgorithm 624 as in a classical handshake. If EncryptedCliS is received, the 625 server decrypts the ciphertext(s) with the appropriate private secret 626 key(s) and obtains CliS. Otherwise, the server sets CliS to NULL. 628 The final premaster secret negotiated by the client and the server is 629 the concatenation of the classical premaster secret, SerS, and CliS 630 in that order. A 48 bytes fixed length master secret is derived from 631 the premaster secret at the end of the handshake, using a pseudo 632 random function specified by the classical cipher suite (see Section 633 8.1. RFC 5246 [RFC5246]). 635 4. Cipher Suites 637 CipherSuite TLS_QSH = { 0xD0, 0x01 } 639 Implementations that support this cipher suite MUST support at least 640 one classical cipher suite. 642 5. Specific information for Quantum Safe Scheme 644 5.1 NTRUEncrypt 646 NTRUEncrypt parameter sets are identified by the values ntru_eess439 647 (0x0101), ntru_eess593 (0x0102), ntru_eess743 (0x0103) assigned in 648 this document. 650 For each of these parameter sets, the public key and ciphertext are 651 Ring Elements as defined in [EESS1]. The encoded public key and 652 ciphertext are the result of encoding the relevant Ring Element with 653 RE2BSP as defined in [EESS1]. 655 For each parameter set the the maximum plaintext input length in 656 bytes is as follows. This is used when determining the length of the 657 client/server-generated secrets CliSi and SerSi as specified in 658 sections 3.4 and 3.5. 660 eess439 65 661 eess593 86 662 eess743 106 664 5.2. LWE 665 Encoding not defined in this document. 667 5.3. HFE 668 Encoding not defined in this document. 670 6. Security Considerations 672 6.1. Security, Authenticity and Forward Secrecy 674 Security, authenticity and forward secrecy against classical 675 computers are inherent from classical handshake mechanism. 677 6.2. Quantum Security and Quantum Forward Secrecy 679 The proposed handshake mechanism provides quantum security and 680 quantum forward secrecy. 682 Quantum resistant feature of QSHSchemes ensures a quantum attacker 683 will not learn SerS and/or CliS. A quantum attacker may learn 684 classic handshake information. Given an input X, the leftover hash 685 lemma [LHL] ensures that one can extract Y bits that are almost 686 uniformly distributed, where Y is asymptotic to the min-entropy of X. 687 An adversary who has some partial knowledge about X, will have almost 688 no knowledge about Y. This guarantees the attacker will not learn 689 the final premaster secret so long as SerS and/or CliS have enough 690 entropy and remain secret. This also guarantees the premaster secret 691 is secure even if the client's and/or the server's long term keys are 692 compromised. 694 6.3. Quantum Authenticity 695 The proposed approach relies on the classical cipher suite for 696 authenticity. Thus, an attacker with quantum computing capability 697 will be able to break the authenticity. 699 7. IANA Considerations 701 This document describes a new name spaces for use with the TLS 702 protocol: 704 o QSHSchemeID 706 Any additional assignments require IETF Consensus action [RFC2434]. 708 8. Acknowledgements 710 Funding for the RFC Editor function is provided by the IETF 711 Administrative Support Activity (IASA). 713 9. References 715 9.1. Normative References 717 [EESS1] Consortium for Efficient Embedded Security, "Efficient 718 Embedded Security Standard #1: Implementation Aspects of 719 NTRUEncrypt", March 2015. 720 723 [FIPS180] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 725 [FIPS186] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 727 [LHL] Impagliazzo, R., Levin, L., and Luby, M., "Pseudo-random 728 generation from one-way functions", 1989. 730 [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 731 1.5", PKCS 1, November 1993 733 [REAL] "RFC Editor Abbreviations List", September 2013, 734 . 737 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 738 Requirement Levels", RFC 2119, March 1997. 740 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 741 RFC 2246, January 1999. 743 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 744 IANA Considerations Section in RFCs", RFC 2434, October 745 1998. 747 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 748 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 750 [RFC4366] Blake-Wilson, S., Nysrom, M., Hopwood, D., Mikkelsen, J., 751 and T. Wright, "Transport Layer Security (TLS) 752 Extensions", RFC 4366, April 2006. 754 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 755 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 756 for Transport Layer Security (TLS)", RFC 4492, May 2006. 758 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 759 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 761 [TLS1.3] E. Rescorla, "The Transport Layer Security (TLS) Protocol 762 Version 1.3", draft-ietf-tls-tls13-05, March 2015. 764 8.2. Informative References 766 [RFC5990] Randall, J., Kaliski, B., Brainard, J. and Turner S., "Use 767 of the RSA-KEM Key Transport Algorithm in the 768 Cryptographic Message Syntax (CMS)", RFC 5990, September 769 2010. 771 [RFC5859] Krawczyk, H., Eronen, P., "HMAC-based Extract-and-Expand 772 Key Derivation Function (HKDF)", RFC 5859, May 2010. 774 Authors' Addresses 776 John M. Schanck 777 Security Innovation, US 778 and 779 University of Waterloo, Canada 780 jschanck@securityinnovation.com 782 William Whyte 783 Security Innovation, US 784 wwhyte@securityinnovation.com 786 Zhenfei Zhang 787 Security Innovation, US 788 zzhang@securityinnovation.com 790 Copyright Notice 792 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 793 2: Copyright (c) 2015 IETF Trust and the persons identified as the 794 document authors. All rights reserved. 796 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii), 797 paragraph 3: This document is subject to BCP 78 and the IETF Trust's 798 Legal Provisions Relating to IETF Documents 799 (http://trustee.ietf.org/license-info) in effect on the date of 800 publication of this document. Please review these documents 801 carefully, as they describe your rights and restrictions with respect 802 to this document.