idnits 2.17.1
draft-whyte-qsh-tls13-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 476 has weird spacing: '...eyShare cla...'
== Line 518 has weird spacing: '...eyShare cla...'
-- The document date (21 July 2015) is 3195 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'SECG' is mentioned on line 77, but not defined
== Missing Reference: 'XXXX' is mentioned on line 97, but not defined
== Missing Reference: 'IANA' is mentioned on line 279, but not defined
== Unused Reference: 'FIPS180' is defined on line 660, but no explicit
reference was found in the text
== Unused Reference: 'FIPS186' is defined on line 662, but no explicit
reference was found in the text
== Unused Reference: 'RFC5990' is defined on line 703, but no explicit
reference was found in the text
== Unused Reference: 'RFC5859' is defined on line 708, 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 (~~), 10 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
11 for Transport Layer Security (TLS) version 1.3
12 draft-whyte-qsh-tls13-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.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 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 . . . . . 7
51 3.2. Client Hello Extensions . . . . . . . . . . . . . . . . . 9
52 3.3. HelloRetryRequest Extensions . . . . . . . . . . . . . . . 11
53 3.4. Client Key Share . . . . . . . . . . . . . . . . . . . . . 12
54 3.5. Server Key Share . . . . . . . . . . . . . . . . . . . . . 12
55 4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 14
56 5. Specific information for Quantum Safe Scheme . . . . . . . . . 14
57 5.1 NTRUEncrypt . . . . . . . . . . . . . . . . . . . . . . . 14
58 5.2. LWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
59 5.3. HFE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
61 6.1. Security, Authenticity and Forward Secrecy . . . . . . . . 15
62 6.2. Quantum Security and Quantum Forward Secrecy . . . . . . . 15
63 6.3. Quantum Authenticity . . . . . . . . . . . . . . . . . . . 15
64 7. Compatibility with TLS 1.2 and earlier version . . . . . . . . 15
65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
68 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
69 10.2. Informative References . . . . . . . . . . . . . . . . . 17
70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
71 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 19
73 1. Introduction
75 Quantum computers pose a significant threat to modern cryptography.
76 Two most widely adopted public key cryptosystems, namely, RSA [PKCS1]
77 and Elliptic Curve Cryptography (ECC) [SECG], will be broken by
78 general purpose quantum computers. RSA is adopted in TLS from
79 Version 1.0 and to TLS Version 1.3 [RFC2246], [RFC4346], [RFC5246],
80 [TLS1.3]. ECC is enabled in RFC 4492 [RFC4492] and adopted in TLS
81 version 1.2 [RFC5246] and version 1.3 [TLS1.3]. On the other hand,
82 there exist several quantum-safe cryptosystems, such as the
83 NTRUEncrypt cryptosystem [EESS1], that deliver similar performance,
84 yet are conjectured to be robust against quantum computers.
86 This document describes a modular design that allows one or many
87 quantum-safe cryptosystems to be adopted in the handshake protocol,
88 applicable to TLS Version 1.3 [TLS1.3]. It uses a hybrid approach
89 that combines a classical handshake mechanism with key encapsulation
90 mechanisms instantiated with quantum-safe encryption schemes. The
91 modular design provides quantum-safe features to TLS 1.3 with an
92 introduction of only one new cipher suite. Yet, it allows the
93 flexibility to include new and advanced quantum-safe encryption
94 schemes at present and in the future.
96 Extensions to TLS 1.2 [RFC5246] and earlier versions can be found in
97 [XXXX].
99 The remainder of this document is organized as follows. Section 2
100 provides an overview of the modular design of quantum-safe handshake
101 for TLS 1.3. Section 3 specifies various data structures needed for
102 a quantum safe handshake, their encoding in TLS messages, and the
103 processing of those messages. Section 4 defines new TLS_QSH cipher
104 suites. Section 5 provides specific information for quantum safe
105 encryption schemes. Section 6 discusses security considerations.
106 Section 7 discusses compatibility with other versions of TLS.
107 Section 8 describes IANA considerations for the name spaces created
108 by this document. Section 9 gives acknowledgements.
110 This is followed by the lists of normative and informative references
111 cited in this document, the authors' contact information, and
112 statements on intellectual property rights and copyrights.
114 Implementation of this specification requires familiarity with TLS
115 [RFC2246], [RFC4346], [RFC5246], [TLS1.3], TLS extensions [RFC4366],
116 and knowledge of the corresponding quantum-safe cryptosystem.
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120 document are to be interpreted as described in RFC 2119 [RFC2119].
122 Well-known abbreviations and acronyms can be found at RFC Editor
123 Abbreviations List [REAL].
125 2. Modular design for quantum-safe hybrid handshake
127 This document introduces a modular approach to including new quantum-
128 safe key exchange algorithms within TLS 1.3, while maintaining the
129 assurance that comes from the use of already established cipher
130 suites. It allows the TLS premaster secret to be agreed using both
131 an established classical cipher suite and a quantum-safe key
132 encapsulation mechanism.
134 Client Server
136 ClientHello
137 ClientKeyShare -------->
138 <-------- HelloRetryRequest
140 ClientHello
141 ClientKeyShare -------->
142 ServerHello
143 ServerKeyShare
144 {EncryptedExtensions*}
145 {Certificate*}
146 {CertificateRequest*+}
147 {CertificateVerify*}
148 <-------- {Finished}
149 {Certificate*+}
150 {CertificateVerify*+}
151 {Finished} -------->
152 [Application Data] <-------> [Application Data]
154 * message is not sent under some conditions
155 + message is not sent unless client authentication
156 is desired
158 Figure 1: Message flow in a full TLS 1.3 handshake
160 Figure 1 shows all messages involved in the TLS key establishment
161 protocol (aka full handshake). The addition of quantum-safe
162 cryptography has direct impact only on the ClientHello, the
163 ClientKeyShare, the HelloRetryRequest, and the ServerKeyShare
164 messages. In the rest of this document, we describe each quantum-
165 safe key exchange data structure in greater detail in terms of the
166 content and processing of these messages.
168 The authentication is provided by classical cryptography. The
169 introduction of quantum-safe encryption schemes delivers forward
170 secrecy against quantum attackers. The additional cryptographic data
171 exchanged between the client and the server is shown in Figure 2.
173 Client Server
175 ClientHelloExtension
176 (QSHSchemeIDList) -------->
177 HelloRetryRequest
178 <-------- (AcceptQSHSchemeIDList)
179 ClientHello
180 ClientKeyShare
181 (QSHPKList) --------> ServerHello
182 ServerKeyShare
183 (QSHCipherList)
184 <-------- {Finished}
185 {Finished} -------->
187 ClassicSecret|QSHSecret <-------> ClassicSecret|QSHSecret
189 Figure 2: Additional cryptographic data in TLS handshake
191 As usual, the ClientHello message includes the list of classical
192 cipher suites the client wishes to negotiate (e.g.,
193 TLS_ECDH_ECDSA_WITH_NULL_SHA), as well as a new cipher suite
194 identifier TLS_QSH (short for TLS with Quantum Safe Hybrid
195 handshake). This new identifier SHOULD appear first in the list of
196 cipher suites.
198 The extension field of the first ClientHello message MUST have an
199 additional field:
200 o QSHSchemeIDList:
201 a list of distinct QSHSchemeIDs from the client,
202 each ID represents a quantum safe encryption
203 scheme/parameter set supported by the client
205 The extension field of the HelloRetryRequest message MUST have an
206 additional field:
207 o AcceptQSHSchemeIDList:
208 a list of distinct QSHSchemeIDs from the server,
209 each ID represents a quantum safe encryption
210 scheme/parameter set supported/selected by the server
212 If AcceptQSHSchemeIDList in a received HelloRetryRequest message is
213 not null, the ClientKeyShare field MUST have an additional fields:
214 o QSHPKList: a list of client's QSH public keys
215 [QSHPK1]|[QSHPK2]|..., each corresponding to a
216 distinct QSHScheme in AcceptQSHSchemeIDList
218 Additionally, the ClientKeyShare contains the ServerKeyShare material
219 appropriate to the selected classical cipher suite.
221 The ServerKeyShare message MUST contain an additional list of
222 ciphertexts:
223 o QSHCipherList:
224 a list of ciphertests
225 [Encrypt_QSHPK1(QSHS1)]|[Encrypt_QSHPK2(QSHS2)]|...
226 where the QSH secret keying material is
227 QSHSecret = QSHS1|QSHS2|..., and QSHPKi is from
228 QSHPKList.
230 Additionally, the ServerKeyShare contains an indication of the
231 classical cipher suite selected, and the ServerKeyShare material
232 appropriate to that cipher suite.
234 The final premaster secret negotiated by the client and the server is
235 the concatenation of the classical premaster secret, QSHSecret,
236 QSHPK1|QSHPK2|... in that order. A 48 bytes fixed length master
237 secret is derived from the premaster secret at the end of the
238 handshake, using a pseudo random function specified by the classical
239 cipher suite (see Section 8.1. RFC 5246 [RFC5246]).
241 3. Data Structures and Computations
243 This section specifies the data structures and computations used by
244 TLS_QSH cipher suite specified in Sections 2. The presentation
245 language used here is the same as that used in TLS v1.3 [TLS1.3].
246 Since this specification extends TLS, these descriptions should be
247 merged with those in the TLS specification and any others that extend
248 TLS. This means that enum types may not specify all possible values,
249 and structures with multiple formats chosen with a select() clause
250 may not indicate all possible cases.
252 3.1. Data structures for Quantum-safe Crypto Schemes
254 enum {
255 ntru_eess439 (0x0101),
256 ntru_eess593 (0x0102),
257 ntru_eess743 (0x0103),
258 reserved (0x0102..0x01FF),
259 lwe_XXX (0x0201),
260 reserved (0x0202..0x02FF),
261 hfe_XXX (0x0301),
262 reserved (0x0302..0x03FF),
263 reserved (0x0400..0xFEFF),
264 (0xFFFF)
265 } QSHSchemeID;
267 ntru_eess439, etc: Indicates parameter set to be used for the
268 NTRUEncrypt encryption scheme. The name of the parameter sets
269 defined here are those specified in [EESS1].
271 lwe_XXX, etc: Indicates parameters for Learning With Error (LWE)
272 encryption scheme. The name of the parameters defined here are
273 not specified in this document.
275 hfe_XXX, etc: Indicates parameters for Hidden Field Equotion (HFE)
276 encryption scheme. The name of the parameters defined here are
277 not specified in this document.
279 The QSHSchemes name space is maintained by IANA [IANA]. See Section
280 8 for information on how new schemes are added.
282 The server implementation SHOULD support all of the above QSHSchemes,
283 and client implementation SHALL support at least one of them.
285 struct {
286 QSHSchemeID id<1..2^16-1>
287 } QSHIDList;
289 The QSHSchemeIDList and AcceptQSHSchemeIDList are two instances of
290 QSHIDList structure. This structure defines a list of QSHSchemeIDs,
291 each representing a quantum safe encryption scheme.
293 struct {
294 QSHSchemeID id,
295 opaque pubKey<1..2^16-1>
296 } QSHPK;
298 struct {
299 QSHPK keys<1..2^24-1>
300 } QSHPKList;
302 The structure of public keys send from the client to the server,
303 namely, QSHPK, has two fields: QSHSchemeID specifies the
304 corresponding quantum safe encryption scheme, and an opaque encodes
305 the actual public key data following the specification of the
306 corresponding quantum safe encryption scheme. Any entity that
307 reserves a new quantum safe encryption scheme identifier MUST specify
308 how the keys and ciphertexts for that scheme are encoded. See
309 Section 5 for definitions of the encodings of the schemes specified
310 in this document.
312 The QSHPKList is a list of QSHPKs.
314 struct {
315 QSHSchemeID id,
316 opaque encryptedKey<1..2^16-1>
317 } QSHCipher;
319 struct {
320 QSHCipher encryptedKeys<1..2^24-1>
321 } QSHCipherList;
323 The structure of ciphertext send from the server to the client,
324 namely QSHCipher, has two fields: QSHSchemeID specifies the
325 corresponding quantum safe encryption scheme, and an opaque encodes
326 the actual ciphertext following the specification of the
327 corresponding quantum safe encryption scheme.
329 The QSHCipherList is a list of ciphertexts.
331 3.2. Client Hello Extensions
333 This section specifies a TLS extension that can be included with the
334 ClientHello message as described in RFC 4366 [RFC4366].
336 When these extensions are sent:
338 When a client wish to negotiate a handshake using TLS_QSH cipher
339 suite, the extensions MUST be sent along with the first ClientHello
340 message. Follow-up ClientHello message do not use these extensions.
342 Meaning of these extensions:
344 These extensions allow a client to send a list that enumerates
345 QSHSchemeIDs for supported quantum safe cryptosystems.
347 Note: QSHSchemeID MUST be distinct in QSHSchemeIDList.
349 Structure of the extension:
351 The general structure of TLS extensions is described in [RFC4366],
352 and this specification adds a new type to ExtensionType.
354 enum { quantum-safe-hybrid(0x18)} ExtensionType;
356 quantum-safe-hybrid (Supported TLS_QSH Extension): Indicates the list
357 of QSHSchemeIDs supported by the client. For this extension, the
358 opaque extension_data field MUST contain QSHSchemeIDList and its
359 field is not NULL.
361 struct {
362 select (CipherSuite) {
363 case TLS_QSH:
364 QSHSchemeIDList qshSchemeIDList,
365 } ClientHelloExtension;
367 Items in qshSchemeIDList are ordered according to the client's
368 preferences (favorite choice first).
370 As an example, a client that only supports ntru_eess439 (0x0101) and
371 ntru_eess593 (0x0102) and prefers to use ntru_eess439 would encode
372 its qshSchemeIDList as follows:
374 04 01 01 01 02
376 An example of an extension field will therefore look as follows:
378 00 18 | extension length | 00 04 01 01 01 02 | ...
380 Note: the extension type value appearing in these examples is
381 tentative.
383 Actions of the sender:
385 A client that proposes TLS_QSH cipher suites in its ClientHello
386 message appends these extensions (along with any others), enumerating
387 the supported quantum-safe crypto systems that the client wish to use
388 to negotiate keys with the server.
390 Actions of the receiver:
392 A server that receives a ClientHello with a TLS_QSH cipher suite MUST
393 check the extension field to use the client's enumerated capabilities
394 to guide its selection of an appropriate cipher suite. The TLS_QSH
395 cipher suite must be negotiated only if the server can successfully
396 complete the handshake while using the listed quantum-safe
397 cryptosystems from the client.
399 The server will carry out a classic handshake with the client using a
400 classical cipher suite (other than TLS_QSH) indicated by the client.
401 The server will also select a (list of) supported QSHScheme(s),
402 indexed by QSHSchemeID(s). The server will form the
403 AcceptQSHSchemeIDList with its selected schemes. This list will be
404 send back to the client via the extension field of HelloRetryRequest.
406 If a server does not understand the Extension, does not understand
407 the list of quantum-safe encryption schemes, or is unable to complete
408 the TLS_QSH handshake while restricting itself to the enumerated
409 cryptosystems, it MUST NOT negotiate the use of a TLS_QSH cipher
410 suite. Depending on what other cipher suites are proposed by the
411 client and supported by the server, this may result in a fatal
412 handshake failure alert due to the lack of common cipher suites.
414 3.3. HelloRetryRequest Extensions
416 This section specifies a TLS extension that can be included with the
417 HelloRetryRequest message as described in [TLS1.3].
419 When this extension is sent:
421 The server will send this message in response to a ClientHello
422 message where the extension fields contains a QSHSchemeIDList, when
423 it was able to find an acceptable set of QSHSchemes. If it cannot
424 find such a match, it will respond with a handshake failure alert.
426 Meaning of this extension:
428 This extension allows a server to notify the client the ID(s) for the
429 quantum-safe encryption scheme(s) it chooses from the
430 QSHSchemeIDList.
432 Structure of this extension:
434 struct {
435 select (CipherSuite) {
436 case TLS_QSH:
437 QSHSchemeIDList acceptQSHSchemeIDList,
438 } HelloRetryRequestExtension;
440 Actions of the sender:
442 The server selects a number of QSHSchemeIDs in response to a
443 ClientHelloExtension message. The selection is based on client's
444 preference. The QSHSchemeIDs selected MUST exist in the received
445 QSHSchemeIDList. The server form the acceptQSHSchemeIDList with the
446 list of selected QSHSchemeIDs.
448 Actions of the receiver:
450 A client that receives a HelloRetryRequest message containing an
451 extension will extract the agreed QSHSchemeIDs and from the
452 acceptQSHSchemeIDList. Those QSHSchemeIDs will be used when the
453 client generates another ClientHello message.
455 3.4. Client Key Share
457 When this message is sent:
459 This message is sent in all key share algorithms.
461 Meaning of the message:
463 This message is used to convey ephemeral data relating to the key
464 exchange belonging to the client (such as its ephemeral ECDH public
465 key). It is also used to send client's quantum-safe keying material
466 to the server.
468 Structure of this message:
470 The TLS ClientKeyExchange message is extended as follows.
472 struct {
473 select (KeyExchangeAlgorithm) {
474 case QSH:
475 QSHPKList qshPKList,
476 ClientKeyShare classical_exchange
477 } exchange_keys;
478 } ClientKeyShare;
480 Actions of the sender:
482 The client sets classical_exchange to have the contents appropriate
483 for the indicated classical cipher suite.
485 For each QSHSchemeID in the acceptQSHSchemeIDList received in the
486 HelloRetryRequestExtension, the client will generate a pair of
487 public/private keys, and form the qshPKList with those keys, in the
488 corrected order.
490 qshPKList = QSHPK1 | QSHPK2 | ...
492 Actions of the receiver:
494 The server processes the ClientKeyShare with KeyExchangeAlgorithm as
495 in a classical handshake. The server will use the received public
496 key list during generating ServerKeyShare message.
498 3.5. Server Key Share
500 When this message is sent:
502 This message is sent in all implementations of this cipher suite.
504 Meaning of this message:
506 This message is used to send classical key exchange information to
507 the client. It is also used to send QSH key material (encrypted by
508 one or many of the client's public keys) to the client.
510 Structure of this message:
512 The TLS ServerKeyShare message is extended as follows.
514 struct {
515 select (KeyExchangeAlgorithm) {
516 case TLS_QSH:
517 QSHCipherList encryptedQSHSecret,
518 ServerKeyShare classical_exchange,
519 } exchange_keys;
520 } ServerKeyShare;
522 Actions of the sender:
524 The server sets classical_exchange to have the contents appropriate
525 for the indicated classical cipher suite.
527 The server extracts client's public keys QSHPK1, ..., QSHPKn from the
528 ClientKeyShare message. For each of the public keys QSHPKi,
529 generates a secret QSHSi. The length in bytes of QSHSi MUST be the
530 lesser of (a) 48, the length of the classical master secret, and (b)
531 the maximum plaintext input length for the corresponding encryption
532 scheme (see Section 5).
534 The server then encrypts the QSHSi with QSHPKi, and form the
535 encryptedQSHSecret with those ciphertexts.
537 The QSH keying material is:
538 QSHSecret = QSHS1|QSHS2|...|QSHSk
540 The server will finally form the premaster secret as a concatenation
541 of the classical premaster secret (negotiated via
542 classical_exchange), QHSSecret, and QSHPK (the public keys that
543 encrypts the message). A 48 bytes fixed length master secret is
544 derived from the premaster secret at the end of the handshake, using
545 a pseudo random function specified by the classical cipher suite (see
546 Section 8.1. RFC 5246 [RFC5246]).
548 Actions of the receiver:
550 The client processes the ServerKeyShare with classical_exchange as in
551 a classical handshake. The client decrypts each ciphertext in
552 encryptedS using the client's secret key and obtains SerS.
554 The client will finally form the premaster secret as a concatenation
555 of the classical premaster secret (negotiated via
556 classical_exchange), QHSSecret, and QSHPK (the public keys that
557 encrypts the message). A 48 bytes fixed length master secret is
558 derived from the premaster secret at the end of the handshake, using
559 a pseudo random function specified by the classical cipher suite (see
560 Section 8.1. RFC 5246 [RFC5246]).
562 4. Cipher Suites
564 CipherSuite TLS_QSH = { 0xD0, 0x01 }
566 Implementations that support this cipher suite MUST support at least
567 one classical cipher suite.
569 5. Specific information for Quantum Safe Scheme
571 5.1 NTRUEncrypt
573 NTRUEncrypt parameter sets are identified by the values ntru_eess439
574 (0x0101), ntru_eess593 (0x0102), ntru_eess743 (0x0103) assigned in
575 this document.
577 For each of these parameter sets, the public key and ciphertext are
578 Ring Elements as defined in [EESS1]. The encoded public key and
579 ciphertext are the result of encoding the relevant Ring Element with
580 RE2BSP as defined in [EESS1].
582 For each parameter set the the maximum plaintext input length in
583 bytes is as follows. This is used when determining the length of the
584 client/server-generated secrets CliSi and SerSi as specified in
585 sections 3.4 and 3.5.
587 eess439 65
588 eess593 86
589 eess743 106
591 5.2. LWE
592 Encoding not defined in this document.
594 5.3. HFE
595 Encoding not defined in this document.
597 6. Security Considerations
598 6.1. Security, Authenticity and Forward Secrecy
600 Security, authenticity and forward secrecy against classical
601 computers are inherent from classical handshake mechanism.
603 6.2. Quantum Security and Quantum Forward Secrecy
605 The proposed handshake mechanism provides quantum security and
606 quantum forward secrecy.
608 Quantum resistant feature of QSHSchemes ensures a quantum attacker
609 will not learn QSH keying material S. A quantum attacker may learn
610 classic handshake information. Given an input X, the leftover hash
611 lemma [LHL] ensures that one can extract Y bits that are almost
612 uniformly distributed, where Y is asymptotic to the min-entropy of X.
613 An adversary who has some partial knowledge about X, will have almost
614 no knowledge about Y. This guarantees the attacker will not learn
615 the final premaster secret so long as S has enough entropy and
616 remains secret. This also guarantees the premaster secret is secure
617 even if the client's and/or the server's long term keys are
618 compromised.
620 6.3. Quantum Authenticity
622 The proposed approach relies on the classical cipher suite for
623 authenticity. Thus, an attacker with quantum computing capability
624 will be able to break the authenticity.
626 7. Compatibility with TLS 1.2 and earlier version
628 8. IANA Considerations
630 This document describes a new name spaces for use with the TLS
631 protocol:
633 o QSHSchemeID
635 Any additional assignments require IETF Consensus action [RFC2434].
636 Process for determining whether a public key algorithm is in fact
637 quantum-safe, and therefore entitled to a QSHSchemeId, is not
638 specified in this document and may be established by the TLS working
639 group as it sees fit. For example, TLS WG may require that
640 algorithms are vetted in some sense by CFRG or have been published in
641 a standard by a recognized international standards body such as IEEE
642 or ANSI X9.
644 9. Acknowledgements
645 Funding for the RFC Editor function is provided by the IETF
646 Administrative Support Activity (IASA).
648 We wish to thank Douglas Stebila, [[[names]]] for helpful
649 discussions.
651 10. References
653 10.1. Normative References
655 [EESS1] Consortium for Efficient Embedded Security, "Efficient
656 Embedded Security standards (EESS) #1", March 2015,
657 .
660 [FIPS180] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
662 [FIPS186] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
664 [LHL] Impagliazzo, R., Levin, L., and Luby, M., "Pseudo-random
665 generation from one-way functions", 1989.
667 [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
668 1.5", PKCS 1, November 1993
670 [REAL] "RFC Editor Abbreviations List", September 2013,
671 .
674 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
675 Requirement Levels", RFC 2119, March 1997.
677 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
678 RFC 2246, January 1999.
680 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
681 IANA Considerations Section in RFCs", RFC 2434, October
682 1998.
684 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
685 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
687 [RFC4366] Blake-Wilson, S., Nysrom, M., Hopwood, D., Mikkelsen, J.,
688 and T. Wright, "Transport Layer Security (TLS)
689 Extensions", RFC 4366, April 2006.
691 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
692 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
693 for Transport Layer Security (TLS)", RFC 4492, May 2006.
695 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
696 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
698 [TLS1.3] E. Rescorla, "The Transport Layer Security (TLS) Protocol
699 Version 1.3", draft-ietf-tls-tls13-05, March 2015.
701 10.2. Informative References
703 [RFC5990] Randall, J., Kaliski, B., Brainard, J. and Turner S., "Use
704 of the RSA-KEM Key Transport Algorithm in the
705 Cryptographic Message Syntax (CMS)", RFC 5990, September
706 2010.
708 [RFC5859] Krawczyk, H., Eronen, P., "HMAC-based Extract-and-Expand
709 Key Derivation Function (HKDF)", RFC 5859, May 2010.
711 Authors' Addresses
713 John M. Schanck
714 Security Innovation, US
715 and
716 University of Waterloo, Canada
717 jschanck@securityinnovation.com
719 William Whyte
720 Security Innovation, US
721 wwhyte@securityinnovation.com
723 Zhenfei Zhang
724 Security Innovation, US
725 zzhang@securityinnovation.com
727 Copyright Notice
729 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph
730 2: Copyright (c) 2015 IETF Trust and the persons identified as the
731 document authors. All rights reserved.
733 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii),
734 paragraph 3: This document is subject to BCP 78 and the IETF Trust's
735 Legal Provisions Relating to IETF Documents
736 (http://trustee.ietf.org/license-info) in effect on the date of
737 publication of this document. Please review these documents
738 carefully, as they describe your rights and restrictions with respect
739 to this document.