idnits 2.17.1
draft-whyte-qsh-tls13-03.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
-- The document date (2016-10-04) is 2759 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'SECG' is mentioned on line 83, but not defined
== Missing Reference: 'IANA' is mentioned on line 356, but not defined
== Unused Reference: 'FIPS180' is defined on line 759, but no explicit
reference was found in the text
== Unused Reference: 'FIPS186' is defined on line 761, but no explicit
reference was found in the text
== Unused Reference: 'H2020' is defined on line 763, but no explicit
reference was found in the text
== Unused Reference: 'HOF15' is defined on line 766, but no explicit
reference was found in the text
== Unused Reference: 'LIN11' is defined on line 770, but no explicit
reference was found in the text
== Unused Reference: 'MCBIT' is defined on line 776, but no explicit
reference was found in the text
== Unused Reference: 'MCELI' is defined on line 779, but no explicit
reference was found in the text
== Unused Reference: 'RFC5990' is defined on line 833, but no explicit
reference was found in the text
== Unused Reference: 'RFC5859' is defined on line 841, 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 (~~), 14 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: 2017-04-04 W. Whyte
5 Security Innovation
6 Z. Zhang
7 Security Innovation
8 2016-10-04
10 Quantum-Safe Hybrid (QSH) Ciphersuite
11 for Transport Layer Security (TLS) version 1.3
12 draft-whyte-qsh-tls13-03.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.3. 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 2017-04-04.
45 Update from last version: keeping alive till TLS WG review.
47 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 2. Modular design for quantum-safe hybrid handshake . . . . . . . 4
53 3. Data Structures and Computations . . . . . . . . . . . . . . . 7
54 3.1. Data structures for Quantum-safe Crypto Schemes . . . . . 7
55 3.2. Client Hello Extensions . . . . . . . . . . . . . . . . . 9
56 3.3. HelloRetryRequest Extensions . . . . . . . . . . . . . . . 11
57 3.4. Server Key Share Extension . . . . . . . . . . . . . . . . 12
58 4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 14
59 5. Specific information for Quantum Safe Scheme . . . . . . . . . 14
60 5.1. NTRUEncrypt . . . . . . . . . . . . . . . . . . . . . . . 14
61 5.2. LWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
62 5.3. HFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
63 5.4. McEliece/McBits . . . . . . . . . . . . . . . . . . . . . 15
64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
65 6.1. Security, Authenticity and Forward Secrecy . . . . . . . . 15
66 6.2. Quantum Security and Quantum Forward Secrecy . . . . . . . 15
67 6.3. Quantum Authenticity . . . . . . . . . . . . . . . . . . . 15
68 7. Compatibility with TLS 1.2 and earlier version . . . . . . . . 15
69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
72 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
73 10.2. Informative References . . . . . . . . . . . . . . . . . 17
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
75 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 18
77 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
79 1. Introduction
81 Quantum computers pose a significant threat to modern cryptography.
82 Two most widely adopted public key cryptosystems, namely, RSA [PKCS1]
83 and Elliptic Curve Cryptography (ECC) [SECG], will be broken by
84 general purpose quantum computers. RSA is adopted in TLS from
85 Version 1.0 and to TLS Version 1.3 [RFC2246], [RFC4346], [RFC5246],
86 [TLS1.3]. ECC is enabled in RFC 4492 [RFC4492] and adopted in TLS
87 version 1.2 [RFC5246] and version 1.3 [TLS1.3]. On the other hand,
88 there exist several quantum-safe cryptosystems, such as the
89 NTRUEncrypt cryptosystem [EESS1], that deliver similar performance,
90 yet are conjectured to be robust against quantum computers.
92 This document describes a modular design that allows one or many
93 quantum-safe cryptosystems to be adopted in the handshake protocol,
94 applicable to TLS Version 1.3 [TLS1.3]. It uses a hybrid approach
95 that combines a classical handshake mechanism with key encapsulation
96 mechanisms instantiated with quantum-safe encryption schemes. The
97 modular design provides quantum-safe features to TLS 1.3 without any
98 introduction of extra cipher suites. Yet, it allows the flexibility
99 to include new and advanced quantum-safe encryption schemes at
100 present and in the future.
102 Extensions to TLS 1.2 [RFC5246] and earlier versions can be found in
103 [QSH12].
105 The remainder of this document is organized as follows. Section 2
106 provides an overview of the modular design of quantum-safe handshake
107 for TLS 1.3. Section 3 specifies various data structures needed for
108 a quantum safe handshake, their encoding in TLS messages, and the
109 processing of those messages. Section 4 defines new TLS_QSH cipher
110 suites. Section 5 provides specific information for quantum safe
111 encryption schemes. Section 6 discusses security considerations.
112 Section 7 discusses compatibility with other versions of TLS.
113 Section 8 describes IANA considerations for the name spaces created
114 by this document. Section 9 gives acknowledgements.
116 This is followed by the lists of normative and informative references
117 cited in this document, the authors' contact information, and
118 statements on intellectual property rights and copyrights.
120 Implementation of this specification requires familiarity with TLS
121 [RFC2246], [RFC4346], [RFC5246], [TLS1.3], TLS extensions [RFC4366],
122 and knowledge of the corresponding quantum-safe cryptosystem.
124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
126 document are to be interpreted as described in RFC 2119 [RFC2119].
128 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
130 Well-known abbreviations and acronyms can be found at RFC Editor
131 Abbreviations List [REAL].
133 2. Modular design for quantum-safe hybrid handshake
135 This document introduces a modular approach to including new quantum-
136 safe key exchange algorithms within TLS 1.3, while maintaining the
137 assurance that comes from the use of already established cipher
138 suites. It allows the TLS premaster secret to be agreed using both
139 an established classical cipher suite and a quantum-safe key
140 encapsulation mechanism.
142 Client Server
144 ClientHello
145 ClientKeyShare -------->
146 <-------- HelloRetryRequest
148 ClientHello
149 ClientKeyShare -------->
150 ServerHello
151 ServerKeyShare
152 {EncryptedExtensions*}
153 {Certificate*}
154 {CertificateRequest*+}
155 {CertificateVerify*}
156 <-------- {Finished}
157 {Certificate*+}
158 {CertificateVerify*+}
159 {Finished} -------->
160 [Application Data] <-------> [Application Data]
162 * message is not sent under some conditions
163 + message is not sent unless client authentication
164 is desired
166 Figure 1: Message flow in a full TLS 1.3 handshake
168 Figure 1 shows all messages involved in the TLS key establishment
169 protocol (aka full handshake). The addition of quantum-safe
170 cryptography has direct impact only on the ClientHello, the
171 HelloRetryRequest, and the ServerKeyShare messages. In the rest of
172 this document, we describe each quantum-safe key exchange data
173 structure in greater detail in terms of the content and processing of
174 these messages.
176 The authentication is provided by classical cryptography. The
178 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
180 introduction of quantum-safe encryption schemes delivers forward
181 secrecy against quantum attackers. The additional cryptographic data
182 exchanged between the client and the server is shown in Figure 2 and
183 3.
185 Figure 2 illustrates the data flow of a zero round trip quantum-safe
186 handshake for TLS. This handshake is proceeded when 1) the classical
187 key exchange is also zero round trip, and 2) the server supports the
188 QSH schemes from QSHPKList.
190 Client Server
192 ClientHelloExtension
193 + qshDataExtension
194 (QSHPKList)
195 + qshNegotiateExtension
196 (QSHSchemeIDList) -------->
197 EncryptedExtensions*
198 + qshDataExtension
199 (QSHCipherList)
200 <-------- {Finished}
201 {Finished} -------->
203 ClassicSecret|QSHSecret <-------> ClassicSecret|QSHSecret
205 * previously known as SeverKeyShareExtensions
206 + additional data
208 Figure 2: Additional cryptographic data
209 for a zero round trip TLS handshake
211 In the case that the server does not support the QSH schemes from
212 QSHPKList, the server will reply with a HelloRetryRequest, which
213 results into a full handshake.
215 Client Server
217 ClientHelloExtensions
218 + qshDataExtension
219 (QSHPKList)
220 + qshNegotiateExtension
221 (QSHSchemeIDList) -------->
222 HelloRetryRequestExtensions
223 + qshNegotiateExtension
224 <-------- (AcceptQSHSchemeIDList)
226 ClientHelloExtensions
227 + qshDataExtension
229 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
231 (QSHPKList) -------->
232 EncryptedExtensions*
233 + qshDataExtension
234 (QSHCipherList)
235 <-------- {Finished}
236 {Finished} -------->
238 ClassicSecret|QSHSecret <-------> ClassicSecret|QSHSecret
240 * previously known as SeverKeyShareExtensions
241 + additional data
243 Figure 3: Additional cryptographic data
244 for a full TLS handshake
246 As usual, the ClientHello message includes the list of classical
247 cipher suites the client wishes to negotiate (e.g.,
248 TLS_ECDH_ECDSA_WITH_NULL_SHA). In addition there will be two
249 potential extension fields, indicating qshData and qshNegotiate
250 extensions.
252 The ClientHelloExtension field MUST have qshData extension field:
253 o QSHPKList: a list of distinct public keys for QSH Scheme
254 from the client, each public key for a distinct
255 quantum safe encryption scheme supported by the
256 client.
258 The ClientHelloExtension field MAY have qshNegotiate extension
259 field:
260 o QSHSchemeIDList:
261 a list of distinct QSHSchemeIDs from the client,
262 each ID represents a quantum safe encryption
263 scheme/parameter set supported by the client
265 QSHSchemeIDList must not list the scheme IDs whose public key is
266 already included in the QSHPKList.
268 If the server supports QSH schemes/parameter sets for the public keys
269 received from QSHPKList, the server will proceed the zero round trip
270 handshake, provided that the zero round trip is also permitted by
271 classical handshake. If not, the server will pick a (list of)
272 QSHSchemeID(s) from the QSHSchemeIDList to form the
273 AcceptQSHSchemeIDList, and request public keys for those schemes in a
274 HelloRetryRequest message. If the server does not support any of the
275 QSH schemes from either QSHPKList or QSHSchemeIDList, the server will
276 abort the handshake.
278 The extension field of the HelloRetryRequest message MUST have an
280 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
282 qshNegotiate extension field:
283 o AcceptQSHSchemeIDList:
284 a list of distinct QSHSchemeIDs from the server,
285 each ID represents a quantum safe encryption
286 scheme/parameter set supported/selected by the server
288 The ServerKeyShare message contains an indication of the classical
289 cipher suite selected, and the ServerKeyShare material appropriate to
290 that cipher suite. Additionally, the ServerKeyShareExtension (a.k.a.
291 EncryptedExtension) field message MUST contain a qshData extension
292 field listing ciphertexts:
293 o QSHCipherList:
294 a list of ciphertests
295 [Encrypt_QSHPK1(QSHS1)]|[Encrypt_QSHPK2(QSHS2)]|...
296 where the QSH secret keying material is
297 QSHSecret = QSHS1|QSHS2|..., and QSHPKi is from
298 QSHPKList.
300 The final premaster secret negotiated by the client and the server is
301 the concatenation of the classical premaster secret, QSHSecret,
302 QSHPK1|QSHPK2|... in that order. A 48 bytes fixed length master
303 secret is derived from the premaster secret at the end of the
304 handshake, using a pseudo random function specified by the classical
305 cipher suite (see Section 8.1. RFC 5246 [RFC5246]).
307 3. Data Structures and Computations
309 This section specifies the data structures and computations used by
310 TLS_QSH cipher suite specified in Sections 2. The presentation
311 language used here is the same as that used in TLS v1.3 [TLS1.3].
312 Since this specification extends TLS, these descriptions should be
313 merged with those in the TLS specification and any others that extend
314 TLS. This means that enum types may not specify all possible values,
315 and structures with multiple formats chosen with a select() clause
316 may not indicate all possible cases.
318 3.1. Data structures for Quantum-safe Crypto Schemes
320 enum {
321 ntru_eess443 (0x0101),
322 ntru_eess587 (0x0102),
323 ntru_eess743 (0x0103),
324 reserved (0x0102..0x01FF),
325 lwe_XXX (0x0201),
326 reserved (0x0202..0x02FF),
327 hfe_XXX (0x0301),
328 reserved (0x0302..0x03FF),
329 mcbits_XXX (0x0401),
331 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
333 reserved (0x0402..0x04FF),
334 reserved (0x0500..0xFEFF),
335 (0xFFFF)
336 } QSHSchemeID;
338 ntru_eess443, etc: Indicates parameter set to be used for the
339 NTRUEncrypt encryption scheme. The name of the parameter sets
340 defined here are those specified in [EESS1].
342 lwe_XXX, etc: Indicates parameters for Learning With Error (LWE)
343 encryption scheme. The name of the parameters defined here are
344 not specified in this document.
346 hfe_XXX, etc: Indicates parameters for Hidden Field Equotion (HFE)
347 encryption scheme. The name of the parameters defined here are
348 not specified in this document.
350 mcbits_XXX, etc: Indicates parameters for McEliece encryption
351 scheme instantiated with McBits parameter set. The name of the
352 parameters defined here are not specified in this document.
354 See Section 5 for specific information for quantum safe scheme.
356 The QSHSchemes name space is maintained by IANA [IANA]. See Section
357 8 for information on how new schemes are added.
359 The server implementation SHOULD support all of the above QSHSchemes,
360 and client implementation SHALL support at least one of them.
362 struct {
363 QSHSchemeID id<1..2^16-1>
364 } QSHIDList;
366 The QSHSchemeIDList and AcceptQSHSchemeIDList are two instances of
367 QSHIDList structure. This structure defines a list of QSHSchemeIDs,
368 each representing a quantum safe encryption scheme.
370 struct {
371 QSHSchemeID id,
372 opaque pubKey<1..2^16-1>
373 } QSHPK;
375 struct {
376 QSHPK keys<1..2^24-1>
377 } QSHPKList;
379 The structure of public keys send from the client to the server,
380 namely, QSHPK, has two fields: QSHSchemeID specifies the
382 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
384 corresponding quantum safe encryption scheme, and an opaque encodes
385 the actual public key data following the specification of the
386 corresponding quantum safe encryption scheme. Any entity that
387 reserves a new quantum safe encryption scheme identifier MUST specify
388 how the keys and ciphertexts for that scheme are encoded. See
389 Section 5 for definitions of the encodings of the schemes specified
390 in this document.
392 NOTE: the QSHPK is a opaque of up to (2^24-1) bytes. This may exceed
393 the size limitation of extensions (2^16-1).
395 The QSHPKList is a list of QSHPKs.
397 struct {
398 QSHSchemeID id,
399 opaque encryptedKey<1..2^16-1>
400 } QSHCipher;
402 struct {
403 QSHCipher encryptedKeys<1..2^24-1>
404 } QSHCipherList;
406 The structure of ciphertext send from the server to the client,
407 namely QSHCipher, has two fields: QSHSchemeID specifies the
408 corresponding quantum safe encryption scheme, and an opaque encodes
409 the actual ciphertext following the specification of the
410 corresponding quantum safe encryption scheme.
412 The QSHCipherList is a list of ciphertexts.
414 3.2. Client Hello Extensions
416 This section specifies a TLS extension that can be included with the
417 ClientHello message as described in RFC 4366 [RFC4366].
419 NOTE: To support larger QSH quantum-safe cryptosystems it may be
420 necessary to raise the maximum size of an extension to 2^24-1 octets.
422 When these extensions are sent:
424 When a client wish to negotiate a handshake using TLS_QSH approach,
425 the extensions MUST be sent along with the first ClientHello message.
426 Follow-up ClientHello message MAY also use these extensions when a
427 zero round trip handshake failed.
429 Meaning of these extensions:
431 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
433 qshNegotiate extension allows a client to send a QSHSchemeIDList that
434 enumerates QSHSchemeIDs for supported quantum safe cryptosystems.
435 qshData extension allows a client to send a QSHPKList of public keys
436 for quantum-safe encryption schemes.
438 Note: QSHSchemeID MUST be distinct in QSHSchemeIDList. If
439 qshNegotiate extension and qshData extension are both send within a
440 same ClientHello extension, QSHSchemeIDList must not enumerate
441 QSHschemeIDs whose public keys are already in QSHPKList.
443 Structure of the extensions:
445 The general structure of TLS extensions is described in [RFC4366],
446 and this specification adds a new type to ExtensionType.
448 enum {
449 qshNegotiate(0x18)
450 qshData(0x19)
451 } ExtensionType;
453 qshNegotiate (Supported TLS_QSH Extension): Indicates the list of
454 QSHSchemeIDs supported by the client. For this extension, the
455 opaque extension_data field MAY contain QSHSchemeIDList and its
456 field can be NULL.
458 qshData (Supported TLS_QSH Extension): Indicates the list of
459 QSHScheme public keys supported by the client. For this
460 extension, the opaque extension_data field MUST contain QSHPKList
461 and its field is not NULL.
463 struct {
464 select (ExtensionType) {
465 case qshNegotiate:
466 QSHSchemeIDList qshSchemeIDList,
467 case qshData:
468 QSHPKList qshPKList,
469 }
470 } ClientHelloExtension;
472 Items in both qshPKList and qshSchemeIDList are ordered according to
473 the client's preferences (favorite choice first).
475 As an example, a client that only supports ntru_eess439 (0x0101) and
476 ntru_eess593 (0x0102) and prefers to use ntru_eess439 would encode
477 its qshSchemeIDList as follows:
479 04 01 01 01 02
481 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
483 An example of a qshNegotiate extension field will therefore look as
484 follows:
486 00 18 | extension length | 00 04 01 01 01 02 | ...
488 Note: the extension type value appearing in these examples is
489 tentative.
491 Actions of the sender:
493 If the ClientHello message starts a fresh handshake, a client that
494 proposes TLS_QSH approach in its ClientHello message appends both
495 qshNegotiate and qshData extensions (along with any others),
496 enumerating the supported quantum-safe crypto systems that the client
497 wish to use to negotiate keys with the server.
499 If the ClientHello message is in response to a HelloRetryRequest, the
500 client appends qshData extension (along with any others), enumerating
501 the QSHScheme public keys supported by the server.
503 Actions of the receiver:
505 A server that receives a ClientHello with a TLS_QSH approach MUST
506 check the extension field to use the client's enumerated capabilities
507 to guide its selection of appropriate quantum safe encryption
508 algorithms. The TLS_QSH approach must be negotiated only if the
509 server can successfully complete the handshake while using the listed
510 quantum-safe cryptosystems from the client.
512 The server will carry out a classic handshake with the client using a
513 classical cipher suite indicated by the ClientHello message. If the
514 server supports QSHSchemes of public keys included in the qshData
515 extension, the server will include a QSHCipherList in the
516 EncryptedExtension field of ServerKeyShare message; if not, the
517 server will select a (list of) supported QSHScheme(s), indexed by
518 QSHSchemeID(s), and form the AcceptQSHSchemeIDList with its selected
519 schemes. This list will be send back to the client via the extension
520 field of HelloRetryRequest.
522 If a server does not understand the Extension, does not understand
523 the list of quantum-safe encryption schemes, or is unable to complete
524 the TLS_QSH handshake while restricting itself to the enumerated
525 cryptosystems, it MUST NOT negotiate the use of a TLS_QSH approach.
526 Depending on what other cipher suites are proposed by the client and
527 supported by the server, this may result in a fatal handshake failure
528 alert due to the lack of common cipher suites.
530 3.3. HelloRetryRequest Extensions
531 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
533 This section specifies a TLS extension that can be included with the
534 HelloRetryRequest message as described in [TLS1.3].
536 When this extension is sent:
538 The server will send this message in response to a ClientHello
539 message where the extension fields contains a extension type quantum-
540 safe-hybrid, when it was able to find an acceptable set of QSHSchemes
541 from qshNegotiate but not from qshData. If it cannot find such a
542 match, it will respond with a handshake failure alert.
544 Meaning of this extension:
546 This extension allows a server to notify the client the ID(s) for the
547 quantum-safe encryption scheme(s) it chooses from the
548 QSHSchemeIDList.
550 Structure of this extension:
552 struct {
553 select (ExtensionType) {
554 case qshNegotiate:
555 QSHSchemeIDList acceptQSHSchemeIDList,
556 }
557 } HelloRetryRequestExtension;
559 Actions of the sender:
561 The server selects a number of QSHSchemeIDs in response to a
562 ClientHelloExtension message. The selection is based on client's
563 preference. The QSHSchemeIDs selected MUST exist in the received
564 QSHSchemeIDList. The server form the acceptQSHSchemeIDList with the
565 list of selected QSHSchemeIDs.
567 Actions of the receiver:
569 A client that receives a HelloRetryRequest message containing an
570 extension type qshNegotiate will extract the agreed QSHSchemeIDs and
571 from the acceptQSHSchemeIDList. Those QSHSchemeIDs will be used when
572 the client generates another ClientHello message.
574 3.4. Server Key Share Extension
576 [[This may be later on changed into *EncryptedExtensions* let's see
577 how TLS 1.3 will define it]]
579 NOTE: To support larger QSH quantum-safe cryptosystems it may be
580 necessary to raise the maximum size of an extension to 2^24-1 octets.
582 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
584 When this message is sent:
586 The server will include this extension field in response to a
587 ClientHello message with extension type qshData.
589 Meaning of this message:
591 It is used to send QSH key material (encrypted by one or many of the
592 client's public keys) to the client.
594 Structure of this message:
596 The TLS ServerKeyShareExtension field is extended as follows.
598 struct {
599 select (ExtensionType) {
600 case qshData:
601 QSHCipherList encryptedQSHSecret,
602 }
603 } ServerKeyShare;
605 Actions of the sender:
607 The server extracts client's public keys QSHPK1, ..., QSHPKn from the
608 qshData field in the received Client Hello extensions. For each of
609 the public keys QSHPKi, generates a secret QSHSi. The length in
610 bytes of QSHSi MUST be the lesser of (a) 48, the length of the
611 classical master secret, and (b) the maximum plaintext input length
612 for the corresponding encryption scheme (see Section 5).
614 The server then encrypts the QSHSi with QSHPKi, and form the
615 encryptedQSHSecret with those ciphertexts.
617 The QSH keying material is:
618 QSHSecret = QSHS1|QSHS2|...|QSHSk
620 The server will finally form the premaster secret as a concatenation
621 of the classical premaster secret (negotiated via classical exchange,
622 i.e., Key Share messages), QHSSecret, and QSHPK (the public keys that
623 encrypts the message). A 48 bytes fixed length master secret is
624 derived from the premaster secret at the end of the handshake, using
625 a pseudo random function specified by the classical cipher suite (see
626 Section 8.1. RFC 5246 [RFC5246]).
628 Actions of the receiver:
630 The client processes the ServerKeyShareExtension
632 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
634 by decrypting each ciphertext in encryptedQSHSecret using the
635 client's secret key and obtaining QSHSecret.
637 The client will finally form the premaster secret as a concatenation
638 of the classical premaster secret (negotiated via classical exchange,
639 i.e., Key Share messages), QHSSecret, and QSHPK (the public keys that
640 encrypts the message). A 48 bytes fixed length master secret is
641 derived from the premaster secret at the end of the handshake, using
642 a pseudo random function specified by the classical cipher suite (see
643 Section 8.1. RFC 5246 [RFC5246]).
645 4. Cipher Suites
647 The TLS_QSH approach does not introduce any additional cipher suite
648 identifiers.
650 5. Specific information for Quantum Safe Scheme
652 Selection criteria for qauntum-safe cryptography to be used in this
653 TLS_QSH approach can be found at [QSHPKC]. Also see [PQCRY] for
654 initial recommendations of quantum safe cryptography from EU's
655 PQCRYPTO project.
657 5.1. NTRUEncrypt
659 NTRUEncrypt parameter sets are identified by the values ntru_eess443
660 (0x0101), ntru_eess587 (0x0102), ntru_eess743 (0x0103) assigned in
661 this document.
663 For each of these parameter sets, the public key and ciphertext are
664 Ring Elements as defined in [EESS1]. The encoded public key and
665 ciphertext are the result of encoding the relevant Ring Element with
666 RE2BSP as defined in [EESS1].
668 For each parameter set the the maximum plaintext input length in
669 bytes is as follows. This is used when determining the length of the
670 client/server-generated secrets CliSi and SerSi as specified in
671 sections 3.4 and 3.5.
673 eess443 49
674 eess587 76
675 eess743 106
677 5.2. LWE
678 Encoding not defined in this document.
680 5.3. HFE
681 Encoding not defined in this document.
683 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
685 5.4. McEliece/McBits
686 Encoding not defined in this document.
688 6. Security Considerations
690 6.1. Security, Authenticity and Forward Secrecy
692 Security, authenticity and forward secrecy against classical
693 computers are inherent from classical handshake mechanism.
695 6.2. Quantum Security and Quantum Forward Secrecy
697 The proposed handshake mechanism provides quantum security and
698 quantum forward secrecy.
700 Quantum resistant feature of QSHSchemes ensures a quantum attacker
701 will not learn QSH keying material S. A quantum attacker may learn
702 classic handshake information. Given an input X, the leftover hash
703 lemma [LHL] ensures that one can extract Y bits that are almost
704 uniformly distributed, where Y is asymptotic to the min-entropy of X.
705 An adversary who has some partial knowledge about X, will have almost
706 no knowledge about Y. This guarantees the attacker will not learn
707 the final premaster secret so long as S has enough entropy and
708 remains secret. This also guarantees the premaster secret is secure
709 even if the client's and/or the server's long term keys are
710 compromised.
712 6.3. Quantum Authenticity
714 The proposed approach relies on the classical cipher suite for
715 authenticity. Thus, an attacker with quantum computing capability
716 will be able to break the authenticity.
718 7. Compatibility with TLS 1.2 and earlier version
720 Compatibility with TLS 1.2 and earlier version can be found in
721 [QSH12].
723 8. IANA Considerations
725 This document describes a new name spaces for use with the TLS
726 protocol:
728 o QSHSchemeID
730 Any additional assignments require IETF Consensus action [RFC2434].
731 Process for determining whether a public key algorithm is in fact
732 quantum-safe, and therefore entitled to a QSHSchemeId, is not
734 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
736 specified in this document and may be established by the TLS working
737 group as it sees fit. For example, TLS WG may require that
738 algorithms are vetted in some sense by CFRG or have been published in
739 a standard by a recognized international standards body such as IEEE
740 or ANSI X9.
742 9. Acknowledgements
744 Funding for the RFC Editor function is provided by the IETF
745 Administrative Support Activity (IASA).
747 We wish to thank Douglas Stebila, [[[names]]] for helpful
748 discussions.
750 10. References
752 10.1. Normative References
754 [EESS1] Consortium for Efficient Embedded Security, "Efficient
755 Embedded Security standards (EESS) #1", March 2015,
756 .
759 [FIPS180] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
761 [FIPS186] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
763 [H2020] Lange, T., "PQCRYPTO project in the EU", April, 2015.
764
766 [HOF15] Hoffstein, J., Pipher, J., Schanck, J., Silverman, J.,
767 Whyte, W., and Zhang, Z., "Choosing Parameters for
768 NTRUEncrypt", 2015.
770 [LIN11] Lindner, R., and Peikert, C., "Better Key Sizes (and
771 Attacks) for LWE-Based Encryption", 2011.
773 [LHL] Impagliazzo, R., Levin, L., and Luby, M., "Pseudo-random
774 generation from one-way functions", 1989.
776 [MCBIT] Bernstein, D., Chou, T., and Schwabe, P., "McBits: Fast
777 Constant-Time Code- Based Cryptography", 2013.
779 [MCELI] McEliece, R., "A Public-Key Cryptosystem Based On
780 Algebraic Coding Theory", 1978.
782 [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
783 1.5", PKCS 1, November 1993
785 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
787 [PQCRY] PQCRYPTO, "Initial recommendations of long-term secure
788 post-quantum systems".
789
791 [QSH12] Schanck, J., Whyte, W., and Zhang, Z., "Quantum-Safe
792 Hybrid (QSH) Ciphersuite for Transport Layer Security
793 (TLS) version 1.2", draft-whyte-qsh-tls12-00, July 2015.
795 [QSHPKC] Schanck, J., Whyte, W., and Zhang, Z., "Criteria for
796 selection of public-key cryptographic algorithms for
797 quantum-safe hybrid cryptography", draft-whyte-select-pkc-
798 qsh-00.txt, Sep 2015.
800 [REAL] "RFC Editor Abbreviations List", September 2013,
801 .
804 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
805 Requirement Levels", RFC 2119, March 1997.
807 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
808 RFC 2246, January 1999.
810 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
811 IANA Considerations Section in RFCs", RFC 2434, October
812 1998.
814 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
815 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
817 [RFC4366] Blake-Wilson, S., Nysrom, M., Hopwood, D., Mikkelsen, J.,
818 and T. Wright, "Transport Layer Security (TLS)
819 Extensions", RFC 4366, April 2006.
821 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
822 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
823 for Transport Layer Security (TLS)", RFC 4492, May 2006.
825 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
826 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
828 [TLS1.3] E. Rescorla, "The Transport Layer Security (TLS) Protocol
829 Version 1.3", draft-ietf-tls-tls13-05, March 2015.
831 10.2. Informative References
833 [RFC5990] Randall, J., Kaliski, B., Brainard, J. and Turner S., "Use
835 INTERNET DRAFT Quantum-safe handshake for TLS 1.3 2016-10-04
837 of the RSA-KEM Key Transport Algorithm in the
838 Cryptographic Message Syntax (CMS)", RFC 5990, September
839 2010.
841 [RFC5859] Krawczyk, H., Eronen, P., "HMAC-based Extract-and-Expand
842 Key Derivation Function (HKDF)", RFC 5859, May 2010.
844 Authors' Addresses
846 John M. Schanck
847 Security Innovation, US
848 and
849 University of Waterloo, Canada
850 jschanck@securityinnovation.com
852 William Whyte
853 Security Innovation, US
854 wwhyte@securityinnovation.com
856 Zhenfei Zhang
857 Security Innovation, US
858 zzhang@securityinnovation.com
860 Copyright Notice
862 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph
863 2: Copyright (c) 2015 IETF Trust and the persons identified as the
864 document authors. All rights reserved.
866 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii),
867 paragraph 3: This document is subject to BCP 78 and the IETF Trust's
868 Legal Provisions Relating to IETF Documents
869 (http://trustee.ietf.org/license-info) in effect on the date of
870 publication of this document. Please review these documents
871 carefully, as they describe your rights and restrictions with respect
872 to this document.