< draft-stebila-tls-hybrid-design-00.txt   draft-stebila-tls-hybrid-design-01.txt >
Network Working Group D. Stebila Network Working Group D. Stebila
Internet-Draft University of Waterloo Internet-Draft University of Waterloo
Intended status: Informational S. Gueron Intended status: Informational S. Fluhrer
Expires: September 12, 2019 U. Haifa, Amazon Web Services Expires: January 9, 2020 Cisco Systems
March 11, 2019 S. Gueron
U. Haifa, Amazon Web Services
July 08, 2019
Design issues for hybrid key exchange in TLS 1.3 Design issues for hybrid key exchange in TLS 1.3
draft-stebila-tls-hybrid-design-00 draft-stebila-tls-hybrid-design-01
Abstract Abstract
Hybrid key exchange refers to using multiple key exchange algorithms Hybrid key exchange refers to using multiple key exchange algorithms
simultaneously and combining the result with the goal of providing simultaneously and combining the result with the goal of providing
security even if all but one of the component algorithms is broken, security even if all but one of the component algorithms is broken,
and is motivated by transition to post-quantum cryptography. This and is motivated by transition to post-quantum cryptography. This
document categorizes various design considerations for using hybrid document categorizes various design considerations for using hybrid
key exchange in the Transport Layer Security (TLS) protocol version key exchange in the Transport Layer Security (TLS) protocol version
1.3. 1.3 and outlines two concrete instantiations for consideration.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Revision history . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation for use of hybrid key exchange . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Motivation for use of hybrid key exchange . . . . . . . . 4
1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Related work . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Related work . . . . . . . . . . . . . . . . . . . . . . 7
3. Design options . . . . . . . . . . . . . . . . . . . . . . . 9 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Design options . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. (Neg) How to negotiate hybridization and component 3.1. (Neg) How to negotiate hybridization and component
algorithms? . . . . . . . . . . . . . . . . . . . . . . . 9 algorithms? . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Key exchange negotiation in TLS 1.3 . . . . . . . . . 9 3.1.1. Key exchange negotiation in TLS 1.3 . . . . . . . . . 10
3.1.2. (Neg-Ind) Negotiating component algorithms 3.1.2. (Neg-Ind) Negotiating component algorithms
individually . . . . . . . . . . . . . . . . . . . . 9 individually . . . . . . . . . . . . . . . . . . . . 10
3.1.3. (Neg-Comb) Negotiating component algorithms as a 3.1.3. (Neg-Comb) Negotiating component algorithms as a
combination . . . . . . . . . . . . . . . . . . . . . 10 combination . . . . . . . . . . . . . . . . . . . . . 11
3.1.4. Benefits and drawbacks . . . . . . . . . . . . . . . 11 3.1.4. Benefits and drawbacks . . . . . . . . . . . . . . . 12
3.2. (Num) How many component algorithms to combine? . . . . . 12 3.2. (Num) How many component algorithms to combine? . . . . . 13
3.2.1. (Num-2) Two . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. (Num-2) Two . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. (Num-2+) Two or more . . . . . . . . . . . . . . . . 12 3.2.2. (Num-2+) Two or more . . . . . . . . . . . . . . . . 13
3.2.3. Benefits and Drawbacks . . . . . . . . . . . . . . . 12 3.2.3. Benefits and Drawbacks . . . . . . . . . . . . . . . 13
3.3. (Shares) How to convey key shares? . . . . . . . . . . . 12 3.3. (Shares) How to convey key shares? . . . . . . . . . . . 13
3.3.1. (Shares-Concat) Concatenate key shares . . . . . . . 13 3.3.1. (Shares-Concat) Concatenate key shares . . . . . . . 13
3.3.2. (Shares-Multiple) Send multiple key shares . . . . . 13 3.3.2. (Shares-Multiple) Send multiple key shares . . . . . 14
3.3.3. (Shares-Ext-Additional) Extension carrying additional 3.3.3. (Shares-Ext-Additional) Extension carrying additional
key shares . . . . . . . . . . . . . . . . . . . . . 13 key shares . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Benefits and Drawbacks . . . . . . . . . . . . . . . 13 3.3.4. Benefits and Drawbacks . . . . . . . . . . . . . . . 14
3.4. (Comb) How to use keys? . . . . . . . . . . . . . . . . . 14 3.4. (Comb) How to use keys? . . . . . . . . . . . . . . . . . 14
3.4.1. (Comb-Concat) Concatenate keys then KDF . . . . . . . 14 3.4.1. (Comb-Concat) Concatenate keys . . . . . . . . . . . 15
3.4.2. (Comb-XOR) XOR keys then KDF . . . . . . . . . . . . 15 3.4.2. (Comb-KDF-1) KDF keys . . . . . . . . . . . . . . . . 16
3.4.3. (Comb-Chain) Chain of KDF applications for each key . 15 3.4.3. (Comb-KDF-2) KDF keys . . . . . . . . . . . . . . . . 17
3.4.4. (Comb-AltInput) Second shared secret in an alternate 3.4.4. (Comb-XOR) XOR keys . . . . . . . . . . . . . . . . . 18
KDF input . . . . . . . . . . . . . . . . . . . . . . 16 3.4.5. (Comb-Chain) Chain of KDF applications for each key . 18
3.4.5. Benefits and Drawbacks . . . . . . . . . . . . . . . 17 3.4.6. (Comb-AltInput) Second shared secret in an alternate
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 KDF input . . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 3.4.7. Benefits and Drawbacks . . . . . . . . . . . . . . . 20
5.1. Active security . . . . . . . . . . . . . . . . . . . . . 18 3.4.8. Open questions . . . . . . . . . . . . . . . . . . . 21
5.2. Resumption . . . . . . . . . . . . . . . . . . . . . . . 19 4. Candidate instantiations . . . . . . . . . . . . . . . . . . 21
5.3. Failures . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Candidate Instantiation 1 . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1. ClientHello extension supported_groups . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.2. ClientHello extension hybrid_extension . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 4.1.3. ClientHello extension key_share . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . 19 4.1.4. ServerHello extension KeyShareServerHello . . . . . . 23
4.1.5. Key schedule . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Candidate Instantiation 2 . . . . . . . . . . . . . . . . 25
4.2.1. ClientHello extension supported_groups . . . . . . . 26
4.2.2. ClientHello extension KeyShareClientHello . . . . . . 26
4.2.3. ServerHello extension KeyShareServerHello . . . . . . 27
4.2.4. Key schedule . . . . . . . . . . . . . . . . . . . . 27
4.3. Comparing Candidate Instantiation 1 and 2 . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Active security . . . . . . . . . . . . . . . . . . . . . 28
6.2. Resumption . . . . . . . . . . . . . . . . . . . . . . . 28
6.3. Failures . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document categorizes various design decisions one could make This document categorizes various design decisions one could make
when implementing hybrid key exchange in TLS 1.3, with the goal of when implementing hybrid key exchange in TLS 1.3, with the goal of
fostering discussion, providing options for short-term prototypes/ fostering discussion, providing options for short-term prototypes/
experiments, and serving as a basis for eventual standardization. experiments, and serving as a basis for eventual standardization.
This document also includes two concrete instantiations for
consideration, following two different approaches; it is not our
intention that both be standardized.
This document does not propose specific post-quantum mechanisms; see This document does not propose specific post-quantum mechanisms; see
Section 1.3 for more on the scope of this document. Section 1.4 for more on the scope of this document.
Comments are solicited and should be addressed to the TLS working Comments are solicited and should be addressed to the TLS working
group mailing list at tls@ietf.org and/or the author(s). group mailing list at tls@ietf.org and/or the author(s).
1.1. Terminology 1.1. Revision history
o draft-00: Initial version.
o draft-01:
* Add (Comb-KDF-1) (Section 3.4.2) and (Comb-KDF-2)
(Section 3.4.3) options.
* Add Candidate Instantiation 1 (Section 4.1).
* Add Candidate Instantiation 2 (Section 4.2).
1.2. Terminology
For the purposes of this document, it is helpful to be able to divide For the purposes of this document, it is helpful to be able to divide
cryptographic algorithms into two classes: cryptographic algorithms into two classes:
o "Traditional" algorithms: Algorithms which are widely deployed o "Traditional" algorithms: Algorithms which are widely deployed
today, but which may be deprecated in the future. In the context today, but which may be deprecated in the future. In the context
of TLS 1.3 in 2019, examples of traditional key exchange of TLS 1.3 in 2019, examples of traditional key exchange
algorithms include elliptic curve Diffie-Hellman using secp256r1 algorithms include elliptic curve Diffie-Hellman using secp256r1
or x25519, or finite-field Diffie-Hellman. or x25519, or finite-field Diffie-Hellman.
skipping to change at page 4, line 5 skipping to change at page 4, line 41
algorithms that are being combined in a hybrid key exchange. algorithms that are being combined in a hybrid key exchange.
The primary motivation of this document is preparing for post-quantum The primary motivation of this document is preparing for post-quantum
algorithms. However, it is possible that public key cryptography algorithms. However, it is possible that public key cryptography
based on alternative mathematical constructions will be required based on alternative mathematical constructions will be required
independent of the advent of a quantum computer, for example because independent of the advent of a quantum computer, for example because
of a cryptanalytic breakthrough. As such we opt for the more generic of a cryptanalytic breakthrough. As such we opt for the more generic
term "next-generation" algorithms rather than exclusively "post- term "next-generation" algorithms rather than exclusively "post-
quantum" algorithms. quantum" algorithms.
1.2. Motivation for use of hybrid key exchange 1.3. Motivation for use of hybrid key exchange
Ideally, one would not use hybrid key exchange: one would have Ideally, one would not use hybrid key exchange: one would have
confidence in a single algorithm and parameterization that will stand confidence in a single algorithm and parameterization that will stand
the test of time. However, this may not be the case in the face of the test of time. However, this may not be the case in the face of
quantum computers and cryptanalytic advances more generally. quantum computers and cryptanalytic advances more generally.
Many (but not all) of the post-quantum algorithms currently under Many (but not all) of the post-quantum algorithms currently under
consideration are relatively new; they have not been subject to the consideration are relatively new; they have not been subject to the
same depth of study as RSA and finite-field / elliptic curve Diffie- same depth of study as RSA and finite-field / elliptic curve Diffie-
Hellman, and thus we do not necessarily have as much confidence in Hellman, and thus we do not necessarily have as much confidence in
skipping to change at page 4, line 35 skipping to change at page 5, line 23
Moreover, it is possible that even by the end of the NIST Post- Moreover, it is possible that even by the end of the NIST Post-
Quantum Cryptography Standardization Project, and for a period of Quantum Cryptography Standardization Project, and for a period of
time thereafter, conservative users may not have full confidence in time thereafter, conservative users may not have full confidence in
some algorithms. some algorithms.
As such, there may be users for whom hybrid key exchange is an As such, there may be users for whom hybrid key exchange is an
appropriate step prior to an eventual transition to next-generation appropriate step prior to an eventual transition to next-generation
algorithms. algorithms.
1.3. Scope 1.4. Scope
This document focuses on hybrid ephemeral key exchange in TLS 1.3 This document focuses on hybrid ephemeral key exchange in TLS 1.3
[TLS13]. It intentionally does not address: [TLS13]. It intentionally does not address:
o Selecting which next-generation algorithms to use in TLS 1.3, nor o Selecting which next-generation algorithms to use in TLS 1.3, nor
algorithm identifiers nor encoding mechanisms for next-generation algorithm identifiers nor encoding mechanisms for next-generation
algorithms. (The outcomes of the NIST Post-Quantum Cryptography algorithms. (The outcomes of the NIST Post-Quantum Cryptography
Standardization Project [NIST] will inform this choice.) Standardization Project [NIST] will inform this choice.)
o Authentication using next-generation algorithms. (If a o Authentication using next-generation algorithms. (If a
cryptographic assumption is broken due to the advent of a quantum cryptographic assumption is broken due to the advent of a quantum
computer or some other cryptanalytic breakthrough, confidentiality computer or some other cryptanalytic breakthrough, confidentiality
of information can be broken retroactively by any adversary who of information can be broken retroactively by any adversary who
has passively recorded handshakes and encrypted communications. has passively recorded handshakes and encrypted communications.
But session authentication cannot be retroactively broken.) But session authentication cannot be retroactively broken.)
1.4. Goals 1.5. Goals
The primary goal of a hybrid key exchange mechanism is to facilitate The primary goal of a hybrid key exchange mechanism is to facilitate
the establishment of a shared secret which remains secure as long as the establishment of a shared secret which remains secure as long as
as one of the component key exchange mechanisms remains unbroken. as one of the component key exchange mechanisms remains unbroken.
In addition to the primary cryptographic goal, there may be several In addition to the primary cryptographic goal, there may be several
additional goals in the context of TLS 1.3: additional goals in the context of TLS 1.3:
o *Backwards compatibility:* Clients and servers who are "hybrid- o *Backwards compatibility:* Clients and servers who are "hybrid-
aware", i.e., compliant with whatever hybrid key exchange standard aware", i.e., compliant with whatever hybrid key exchange standard
skipping to change at page 6, line 18 skipping to change at page 7, line 9
* Additional round trips added to the protocol. See below. * Additional round trips added to the protocol. See below.
o *No extra round trips:* Attempting to negotiate hybrid key o *No extra round trips:* Attempting to negotiate hybrid key
exchange should not lead to extra round trips in any of the three exchange should not lead to extra round trips in any of the three
hybrid-aware/non-hybrid-aware scenarios listed above. hybrid-aware/non-hybrid-aware scenarios listed above.
o *No duplicate information:* Attempting to negotiate hybrid key o *No duplicate information:* Attempting to negotiate hybrid key
exchange should not mean having to send multiple public keys of exchange should not mean having to send multiple public keys of
the same type. the same type.
1.5. Related work 1.6. Related work
Quantum computing and post-quantum cryptography in general are Quantum computing and post-quantum cryptography in general are
outside the scope of this document. For a general introduction to outside the scope of this document. For a general introduction to
quantum computing, see a standard textbook such as [NIELSEN]. For an quantum computing, see a standard textbook such as [NIELSEN]. For an
overview of post-quantum cryptography as of 2009, see [BERNSTEIN]. overview of post-quantum cryptography as of 2009, see [BERNSTEIN].
For the current status of the NIST Post-Quantum Cryptography For the current status of the NIST Post-Quantum Cryptography
Standardization Project, see [NIST]. For additional perspectives on Standardization Project, see [NIST]. For additional perspectives on
the general transition from classical to post-quantum cryptography, the general transition from classical to post-quantum cryptography,
see for example [ETSI] and [HOFFMAN], among others. see for example [ETSI] and [HOFFMAN], among others.
skipping to change at page 8, line 46 skipping to change at page 9, line 37
* (Shares-Ext-Additional) (Section 3.3.3) Use an extension to * (Shares-Ext-Additional) (Section 3.3.3) Use an extension to
convey key shares for component algorithms. convey key shares for component algorithms.
4. (Comb) (Section 3.4) How should multiple shared secrets be 4. (Comb) (Section 3.4) How should multiple shared secrets be
combined? combined?
* (Comb-Concat) (Section 3.4.1) Concatenate the shared secrets * (Comb-Concat) (Section 3.4.1) Concatenate the shared secrets
then use directly in the TLS 1.3 key schedule. then use directly in the TLS 1.3 key schedule.
* (Comb-XOR) (Section 3.4.2) XOR the shared secrets then use * (Comb-KDF-1) (Section 3.4.2) and (Comb-KDF-2) (Section 3.4.3)
KDF the shared secrets together, then use the output in the
TLS 1.3 key schedule.
* (Comb-XOR) (Section 3.4.4) XOR the shared secrets then use
directly in the TLS 1.3 key schedule. directly in the TLS 1.3 key schedule.
* (Comb-Chain) (Section 3.4.3) Extend the TLS 1.3 key schedule * (Comb-Chain) (Section 3.4.5) Extend the TLS 1.3 key schedule
so that there is a stage of the key schedule for each shared so that there is a stage of the key schedule for each shared
secret. secret.
* (Comb-AltInput) (Section 3.4.4) Use the second shared secret * (Comb-AltInput) (Section 3.4.6) Use the second shared secret
in an alternate (otherwise unused) input in the TLS 1.3 key in an alternate (otherwise unused) input in the TLS 1.3 key
schedule. schedule.
3. Design options 3. Design options
3.1. (Neg) How to negotiate hybridization and component algorithms? 3.1. (Neg) How to negotiate hybridization and component algorithms?
3.1.1. Key exchange negotiation in TLS 1.3 3.1.1. Key exchange negotiation in TLS 1.3
Recall that in TLS 1.3, the key exchange mechanism is negotiated via Recall that in TLS 1.3, the key exchange mechanism is negotiated via
skipping to change at page 14, line 14 skipping to change at page 15, line 5
key may be sent another time.) (Shares-Multiple) (Section 3.3.2) key may be sent another time.) (Shares-Multiple) (Section 3.3.2)
does not result in duplicate key shares. does not result in duplicate key shares.
3.4. (Comb) How to use keys? 3.4. (Comb) How to use keys?
Each component key exchange algorithm establishes a shared secret. Each component key exchange algorithm establishes a shared secret.
These shared secrets must be combined in some way that achieves the These shared secrets must be combined in some way that achieves the
"hybrid" property: the resulting secret is secure as long as at least "hybrid" property: the resulting secret is secure as long as at least
one of the component key exchange algorithms is unbroken. one of the component key exchange algorithms is unbroken.
3.4.1. (Comb-Concat) Concatenate keys then KDF 3.4.1. (Comb-Concat) Concatenate keys
Each party concatenates the shared secrets established by each Each party concatenates the shared secrets established by each
component algorithm in an agreed-upon order, then uses feeds that component algorithm in an agreed-upon order, then feeds that through
through a key derivation function. In the context of TLS 1.3, this the TLS key schedule. In the context of TLS 1.3, this would mean
would mean using the concatenated shared secret in place of the using the concatenated shared secret in place of the (EC)DHE input to
(EC)DHE input to the second call to "HKDF-Extract" in the TLS 1.3 key the second call to "HKDF-Extract" in the TLS 1.3 key schedule:
schedule:
0 0
| |
v v
PSK -> HKDF-Extract = Early Secret PSK -> HKDF-Extract = Early Secret
| |
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
| |
skipping to change at page 15, line 22 skipping to change at page 16, line 10
[BINDEL] analyzes the security of the (Comb-Concat) approach as [BINDEL] analyzes the security of the (Comb-Concat) approach as
abstracted in their "dualPRF" combiner. They show that, if the abstracted in their "dualPRF" combiner. They show that, if the
component KEMs are IND-CPA-secure (or IND-CCA-secure), then the component KEMs are IND-CPA-secure (or IND-CCA-secure), then the
values output by "Derive-Secret" are IND-CPA-secure (respectively, values output by "Derive-Secret" are IND-CPA-secure (respectively,
IND-CCA-secure). An important aspect of their analysis is that each IND-CCA-secure). An important aspect of their analysis is that each
ciphertext is input to the final PRF calls; this holds for TLS 1.3 ciphertext is input to the final PRF calls; this holds for TLS 1.3
since the "Derive-Secret" calls that derive output keys (application since the "Derive-Secret" calls that derive output keys (application
traffic secrets, and exporter and resumption master secrets) include traffic secrets, and exporter and resumption master secrets) include
the transcript hash as input. the transcript hash as input.
3.4.2. (Comb-XOR) XOR keys then KDF 3.4.2. (Comb-KDF-1) KDF keys
Each party feeds the shared secrets established by each component
algorithm in an agreed-upon order into a KDF, then feeds that through
the TLS key schedule. In the context of TLS 1.3, this would mean
first applying "HKDF-Extract" to the shared secrets, then using the
output in place of the (EC)DHE input to the second call to "HKDF-
Extract" in the TLS 1.3 key schedule:
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
Next-Gen |
| v
(EC)DHE -> HKDF-Extract Derive-Secret(., "derived", "")
| |
v v
output -----> HKDF-Extract = Handshake Secret
^^^^^^ |
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
3.4.3. (Comb-KDF-2) KDF keys
Each party concatenates the shared secrets established by each
component algorithm in an agreed-upon order then feeds that into a
KDF, then feeds the result through the TLS key schedule.
Compared with (Comb-KDF-1) (Section 3.4.2), this method concatenates
the (2 or more) shared secrets prior to input to the KDF, whereas
(Comb-KDF-1) puts the (exactly 2) shared secrets in the two different
input slots to the KDF.
Compared with (Comb-Concat) (Section 3.4.1), this method has an
extract KDF application. While this adds computational overhead,
this may provide a cleaner abstraction of the hybridization mechanism
for the purposes of formal security analysis.
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
concatenated 0
shared |
secret -> HKDF-Extract Derive-Secret(., "derived", "")
^^^^^^ | |
v v
output -----> HKDF-Extract = Handshake Secret
^^^^^^ |
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
3.4.4. (Comb-XOR) XOR keys
Each party XORs the shared secrets established by each component Each party XORs the shared secrets established by each component
algorithm (possibly after padding secrets of different lengths), then algorithm (possibly after padding secrets of different lengths), then
uses feeds that through a key derivation function. In the context of feeds that through the TLS key schedule. In the context of TLS 1.3,
TLS 1.3, this would mean using the XORed shared secret in place of this would mean using the XORed shared secret in place of the (EC)DHE
the (EC)DHE input to the second call to "HKDF-Extract" in the TLS 1.3 input to the second call to "HKDF-Extract" in the TLS 1.3 key
key schedule. schedule.
[GIACON] analyzes the security of applying a KDF to the XORed KEM [GIACON] analyzes the security of applying a KDF to the XORed KEM
shared secrets, but their analysis does not quite apply here since shared secrets, but their analysis does not quite apply here since
the transcript of ciphertexts is included in the KDF application the transcript of ciphertexts is included in the KDF application
(though it should follow relatively straightforwardly). (though it should follow relatively straightforwardly).
3.4.3. (Comb-Chain) Chain of KDF applications for each key 3.4.5. (Comb-Chain) Chain of KDF applications for each key
Each party applies a chain of key derivation functions to the shared Each party applies a chain of key derivation functions to the shared
secrets established by each component algorithm in an agreed-upon secrets established by each component algorithm in an agreed-upon
order; roughly speaking: "F(k1 || F(k2))". In the context of TLS order; roughly speaking: "F(k1 || F(k2))". In the context of TLS
1.3, this would mean extending the key schedule to have one round of 1.3, this would mean extending the key schedule to have one round of
the key schedule applied for each component algorithm's shared the key schedule applied for each component algorithm's shared
secret: secret:
0 0
| |
skipping to change at page 16, line 47 skipping to change at page 19, line 47
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
This is the approach used in [SCHANCK]. This is the approach used in [SCHANCK].
[BINDEL] analyzes the security of this approach as abstracted in [BINDEL] analyzes the security of this approach as abstracted in
their nested dual-PRF "N" combiner, showing a similar result as for their nested dual-PRF "N" combiner, showing a similar result as for
the dualPRF combiner that it preserves IND-CPA (or IND-CCA) security. the dualPRF combiner that it preserves IND-CPA (or IND-CCA) security.
Again their analysis depends on each ciphertext being input to the Again their analysis depends on each ciphertext being input to the
final PRF ("Derive-Secret") calls, which holds for TLS 1.3. final PRF ("Derive-Secret") calls, which holds for TLS 1.3.
3.4.4. (Comb-AltInput) Second shared secret in an alternate KDF input 3.4.6. (Comb-AltInput) Second shared secret in an alternate KDF input
In the context of TLS 1.3, the next-generation shared secret is used In the context of TLS 1.3, the next-generation shared secret is used
in place of a currently unused input in the TLS 1.3 key schedule, in place of a currently unused input in the TLS 1.3 key schedule,
namely replacing the "0" "IKM" input to the final "HKDF-Extract": namely replacing the "0" "IKM" input to the final "HKDF-Extract":
0 0
| |
v v
PSK -> HKDF-Extract = Early Secret PSK -> HKDF-Extract = Early Secret
| |
skipping to change at page 17, line 38 skipping to change at page 20, line 38
^^^^^^^^^^^^^^^^^^^^^^ | ^^^^^^^^^^^^^^^^^^^^^^ |
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
+-----> Derive-Secret(...) +-----> Derive-Secret(...)
This approach is not taken in any of the known post-quantum/hybrid This approach is not taken in any of the known post-quantum/hybrid
TLS drafts. However, it bears some similarities to the approach for TLS drafts. However, it bears some similarities to the approach for
using external PSKs in [EXTERN-PSK]. using external PSKs in [EXTERN-PSK].
3.4.5. Benefits and Drawbacks 3.4.7. Benefits and Drawbacks
*New logic.* While (Comb-Concat) (Section 3.4.1) requires new logic *New logic.* While (Comb-Concat) (Section 3.4.1), (Comb-KDF-1)
(Section 3.4.2), and (Comb-KDF-2) (Section 3.4.3) require new logic
to compute the concatenated shared secret, this value can then be to compute the concatenated shared secret, this value can then be
used by the TLS 1.3 key schedule without changes to the key schedule used by the TLS 1.3 key schedule without changes to the key schedule
logic. In contrast, (Comb-Chain) (Section 3.4.3) requires the TLS logic. In contrast, (Comb-Chain) (Section 3.4.5) requires the TLS
1.3 key schedule to be extended for each extra component algorithm. 1.3 key schedule to be extended for each extra component algorithm.
*Philosophical.* The TLS 1.3 key schedule already applies a new stage *Philosophical.* The TLS 1.3 key schedule already applies a new stage
for different types of keying material (PSK versus (EC)DHE), so for different types of keying material (PSK versus (EC)DHE), so
(Comb-Chain) (Section 3.4.3) continues that approach. (Comb-Chain) (Section 3.4.5) continues that approach.
*Efficiency.* (Comb-Chain) (Section 3.4.3) increases the number of *Efficiency.* (Comb-KDF-1) (Section 3.4.2), (Comb-KDF-2)
KDF applications for each component algorithm, whereas (Comb-Concat) (Section 3.4.3), and (Comb-Chain) (Section 3.4.5) increase the number
(Section 3.4.1) and (Comb-AltInput) (Section 3.4.4) keep the number of KDF applications for each component algorithm, whereas (Comb-
of KDF applications the same (though with potentially longer inputs). Concat) (Section 3.4.1) and (Comb-AltInput) (Section 3.4.6) keep the
number of KDF applications the same (though with potentially longer
inputs).
*Extensibility.* (Comb-AltInput) (Section 3.4.4) changes the use of *Extensibility.* (Comb-AltInput) (Section 3.4.6) changes the use of
an existing input, which might conflict with other future changes to an existing input, which might conflict with other future changes to
the use of the input. the use of the input.
*More than 2 component algorithms.* The techniques in (Comb-Concat) *More than 2 component algorithms.* The techniques in (Comb-Concat)
(Section 3.4.1) and (Comb-Chain) (Section 3.4.3) can naturally (Section 3.4.1) and (Comb-Chain) (Section 3.4.5) can naturally
accommodate more than 2 component shared secrets since there is no accommodate more than 2 component shared secrets since there is no
distinction to how each shared secret is treated. (Comb-AltInput) distinction to how each shared secret is treated. (Comb-AltInput)
(Section 3.4.4) would have to make some distinct, since the 2 (Section 3.4.6) would have to make some distinct, since the 2
component shared secrets are used in different ways; for example, the component shared secrets are used in different ways; for example, the
first shared secret is used as the "IKM" input in the 2nd "HKDF- first shared secret is used as the "IKM" input in the 2nd "HKDF-
Extract" call, and all subsequent shared secrets are concatenated to Extract" call, and all subsequent shared secrets are concatenated to
be used as the "IKM" input in the 3rd "HKDF-Extract" call. be used as the "IKM" input in the 3rd "HKDF-Extract" call.
4. IANA Considerations 3.4.8. Open questions
None. At this point, it is unclear which, if any, of the above methods
preserve FIPS compliance: i.e., if one shared secret is from a FIPS-
compliant method (e.g., ECDH), and another shared secret is from a
non-approved method (e.g., post-quantum), is the result still
considered FIPS compliant? Guidance from NIST on this question would
be helpful. Specifically, are any of these approaches acceptable
under either [NIST-SP-800-56C] or [NIST-SP-800-135]?
5. Security Considerations 4. Candidate instantiations
In this section, we describe two candidate instantiations of hybrid
key exchange in TLS 1.3, based on the design considerations framework
above. It is not our intention that both of these instantations be
standardized; we are providing two for discussion and for comparing
and contrasting the two approaches.
4.1. Candidate Instantiation 1
Candidate Instantiation 1 allows for two or more component algorithms
to be combined (Num-2+) (Section 3.2.2), and negotiates the
combination using markers in the "NamedGroup" list as pointers to an
extension listing the algorithms comprising each possible combination
(Neg-Comb-2) (Section 3.1.3.2) following the approach of [WHYTE13].
The client conveys its multiple key shares individually in the
"client_shares" vector of the "ClientHello" "key_share" extension
(Shares-Multiple) (Section 3.3.2). The server conveys its multiple
key shares concatenated together in its "KeyShareServerHello" struct
(Shares-Concat) (Section 3.3.1). The shared secrets are combined by
concatenating them then feeding them through a KDF, then feeding the
result into the TLS 1.3 key schedule (Comb-KDF-2) (Section 3.4.3).
4.1.1. ClientHello extension supported_groups
Following [WHYTE13] section 3.1, the "NamedGroup" enum used by the
client to populate the "supported_groups" extension is extended to
include new code points representing markers for hybrid combinations:
enum {
/* existing named groups */
secp256r1 (23),
...,
/* new code points eventually defined for post-quantum algorithms */
...,
/* new code points reserved for hybrid markers */
hybrid_marker00 (0xFD00),
hybrid_marker01 (0xFD01),
...
hybrid_markerFF (0xFDFF),
/* existing reserved code points */
ffdhe_private_use (0x01FC..0x01FF),
ecdhe_private_use (0xFE00..0xFEFF),
(0xFFFF)
} NamedGroup;
"hybrid_marker" code points do not a priori represent any fixed
combination. Instead, during each session establishment, the client
defines what it wants each "hybrid_marker" code point to represent
using the following extension.
4.1.2. ClientHello extension hybrid_extension
Following [WHYTE13] section 3.2.4, a new "ClientHello"
"hybrid_extension" extension is defined. It is defined as follows:
struct {
NamedGroup hybrid_marker;
NamedGroup components<2..10>;
} HybridMapping;
struct {
HybridMapping map<0..255>;
} HybridExtension;
The "HybridExtension" contains 0 or more "HybridMapping"s. Each
"HybridMapping" corresponds to one of the "hybrid_marker" included in
the "supported_groups" extension, and lists the component algorithms
that are meant to comprise the this hybrid combination, which can be
any of the existing named groups (elliptic curve or finite field),
new code points eventually defined for post-quantum algorithms, or
reserved code points for private use.
4.1.3. ClientHello extension key_share
No syntactical modifications are made to the "KeyShareEntry" or
"KeyShareClientHello" data structures.
Semantically, the client does not send a "KeyShareEntry"
corresponding to any of the "hybrid_marker" code points. Instead,
the client sends "KeyShareEntry" for each of the component algorithms
listed in the "HybridMapping"s.
For example, if the list of "supported_groups" is "secp256r1",
"x25519", "hybrid_marker00", and "hybrid_marker01", where
"hybrid_marker00" comprises "secp256r1" with a fictional post-quantum
algorithm "PQ1", and "hybrid_marker01" comprises "x25519" with "PQ1",
then the client could send three "KeyShareEntry" components: one for
"secp256r1", one for "x25519", and one for "PQ1".
4.1.4. ServerHello extension KeyShareServerHello
The server responds with a "KeyShareServerHello" struct containing a
single "KeyShareEntry", which contains a single "NamedGroup" value
and an opaque "key_exchange" string.
To complete the negotiation of a hybrid algorithm, the server
responds with the "NamedGroup" value being the "hybrid_marker" code
point correspond to the combination that the server was willing to
agree to.
The "key_exchange" string is the octet representation of the
following struct:
struct {
KeyShareEntry key_share<2..10>;
} HybridKeyShare;
where there is one "key_share" entry for each of the components of
this hybrid combination.
Note that the "key_exchange" string has a maximum length of 2^16-1
octets, which may be insufficient for some post-quantum algorithms or
for some hybridizations of multiple post-quantum algorithms. It
remains an open question as to whether this length can be increased
without breaking existing TLS 1.3 implementations.
4.1.5. Key schedule
The component algorithm shared secrets are combined by concatenating
them, then applying a key derivation function, the output of which is
then used in the TLS 1.3 key schedule in place of the (EC)DHE shared
secret. The component shared secrets are concatenated in the order
that they appear in the "components" vector of the "HybridMapping"
extension above.
We provide two options for concatenating the shared secrets, and
would like feedback from the working group in which to proceed with.
Each component algorithm's "shared_secret" is defined by the
algorithm itself, for example the DHE or ECDHE shared secrets as
defined in Section 7.4 of [TLS13], or as defined by post-quantum
methods once standardized in their own documents.
*Option 1: Using data structures.* Option 1 uses a full-fledged TLS
1.3 data structure to represent the list of component shared secrets.
As a result, lengths of each shared secret are unambiguously encoded.
struct SharedSecret {
opaque shared_secret<0..2^16-1>;
}
struct {
SharedSecret component<2..10>;
} HybridSharedSecret;
The "concatenated_shared_secret" is then the octet representation of
the "HybridSharedSecret " struct.
*Option 2: Direct concatenation.* Option 2 directly concatenates the
shared secrets. Option 2 should only be considered if the shared
secret for each algorithm is guarantees to be of a fixed length,
which would imply that, once the component algorithms are fixed,
concatenation is bijective.
concatenated_shared_secret = shared_secret0 | shared_secret1 | ...
In either option, the "concatenated_shared_secret" octet string is
used as the IKM argument of HKDF-Extract, with the zero-length string
as the salt argument. THe output of HKDF-Extract is used as the IKM
argument for HKDF-Extract's calculation of the handshake secret, as
shown below.
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
concatenated 0
shared |
secret -> HKDF-Extract Derive-Secret(., "derived", "")
^^^^^^ | |
v v
output -----> HKDF-Extract = Handshake Secret
^^^^^^ |
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
4.2. Candidate Instantiation 2
Candidate Instantiation 2 allows for exactly two component algorithms
to be combined (Num-2) (Section 3.2.1), and uses code points
standardized for each permissible combination. The client
concatenates its multiple key shares together as a distinct entry in
the "client_shares" vector of the "ClientHello" "key_share" extension
(Shares-Concat) (Section 3.3.1). The server does the same. The
shared secrets are combined by concatenating them then feeding them
through a KDF, then feeding the result into the TLS 1.3 key schedule
(Comb-KDF-2) (Section 3.4.3).
4.2.1. ClientHello extension supported_groups
The "NamedGroup" enum used by the client to populate the
"supported_groups" extension is extended to include new code points
representing each desired combination.
For example,
enum {
/* existing named groups */
secp256r1 (23),
x25519 (0x001D),
...,
/* new code points eventually defined for post-quantum algorithms */
PQ1 (0x????),
PQ2 (0x????),
...,
/* new code points defined for hybrid combinations */
secp256r1_PQ1 (0x????),
secp256r1_PQ2 (0x????),
x25519_PQ1 (0x????),
x25519_PQ2 (0x????),
/* existing reserved code points */
ffdhe_private_use (0x01FC..0x01FF),
ecdhe_private_use (0xFE00..0xFEFF),
(0xFFFF)
} NamedGroup;
4.2.2. ClientHello extension KeyShareClientHello
The client sends a "KeyShareClientHello" struct containing multiple
"KeyShareEntry" values, some of which may correspond to some of the
hybrid combination code points it listed in the "supported_groups"
extension above.
The "KeyShareEntry" for a hybrid combination code point contains an
opaque "key_exchange" string which is the octet representation of the
following struct:
struct {
KeyShareEntry key_share<2..10>;
} HybridKeyShare;
where there is one "key_share" entry for each of the components of
this hybrid combination.
Note that this approach may result in duplication of key shares being
sent; for example, a client wanting to support either the combination
"secp256r1_PQ1" or "x25519_PQ1" would send two "PQ1" key shares.
4.2.3. ServerHello extension KeyShareServerHello
The server responds with a "KeyShareServerHello" struct containing a
single "KeyShareEntry", which contains a single "NamedGroup" value
and an opaque "key_exchange" string. The "key_exchange" string is
the octet representation of the "HybridKeyShare" struct defined
above.
4.2.4. Key schedule
The key schedule is computed as in Candidate Instantiation 1 above.
4.3. Comparing Candidate Instantiation 1 and 2
CI2 requires much less change to negotiation routines - each hybrid
combination is just a new key exchange method, and the concatenation
of key shares and shared secrets can be handled internally to that
method. This comes at the cost, however, of combinatorial explosion
of code points: one code point needs to be standardized for each
desired combination. We have also limited the number of hybrid
algorithms to 2 in CI2 to somewhat limit the explosion of code points
needing to be defined. Concatenating client key shares also risks
sending duplicate key shares, increasing communication sizes.
CI1 requires more change to negotiation routines, since it introduces
new data structures and has an indirect mapping between hybrid
combinations and key shares. Benefits from this approach include
avoiding sending duplicate key shares and not needing to standardize
every possible supported combination. Implementers, however, must do
the work of deciding which combinations of algorithms are meaningful
/ tolerable / desirable from a security perspective, potentially
complicating interoperability.
5. IANA Considerations
If Candidate Instantiation 1 is selected, the TLS Supported Groups
registry will have to be updated to include code points for hybrid
markers.
6. Security Considerations
The majority of this document is about security considerations. As The majority of this document is about security considerations. As
noted especially in Section 3.4, the shared secrets computed in the noted especially in Section 3.4, the shared secrets computed in the
hybrid key exchange should be computed in a way that achieves the hybrid key exchange should be computed in a way that achieves the
"hybrid" property: the resulting secret is secure as long as at least "hybrid" property: the resulting secret is secure as long as at least
one of the component key exchange algorithms is unbroken. While many one of the component key exchange algorithms is unbroken. While many
natural approaches seem to achieve this, there can be subtleties (see natural approaches seem to achieve this, there can be subtleties (see
for example the introduction of [GIACON]). for example the introduction of [GIACON]).
The rest of this section highlights a few unresolved questions The rest of this section highlights a few unresolved questions
related to security. related to security.
5.1. Active security 6.1. Active security
One security consideration that is not yet resolved is whether key One security consideration that is not yet resolved is whether key
encapsulation mechanisms used in TLS 1.3 must be secure against encapsulation mechanisms used in TLS 1.3 must be secure against
active attacks (IND-CCA), or whether security against passive attacks active attacks (IND-CCA), or whether security against passive attacks
(IND-CPA) suffices. Existing security proofs of TLS 1.3 (such as (IND-CPA) suffices. Existing security proofs of TLS 1.3 (such as
[DFGS15], [DOWLING]) are formulated specifically around Diffie- [DFGS15], [DOWLING]) are formulated specifically around Diffie-
Hellman and use an "actively secure" Diffie-Hellman assumption (PRF Hellman and use an "actively secure" Diffie-Hellman assumption (PRF
Oracle Diffie-Hellman (PRF-ODH)) rather than a "passively secure" DH Oracle Diffie-Hellman (PRF-ODH)) rather than a "passively secure" DH
assumption (e.g. decisional Diffie-Hellman (DDH)), but do not claim assumption (e.g. decisional Diffie-Hellman (DDH)), but do not claim
that the actively secure notion is required. In the context of TLS that the actively secure notion is required. In the context of TLS
1.2, [KPW13] show that, at least in one formalization, a passively 1.2, [KPW13] show that, at least in one formalization, a passively
secure assumption like DDH is insufficient (even when signatures are secure assumption like DDH is insufficient (even when signatures are
used for mutual authentication). Resolving this issue for TLS 1.3 is used for mutual authentication). Resolving this issue for TLS 1.3 is
an open question. an open question.
5.2. Resumption 6.2. Resumption
TLS 1.3 allows for session resumption via a pre-shared key. When a TLS 1.3 allows for session resumption via a pre-shared key. When a
pre-shared key is used during session establishment, an ephemeral key pre-shared key is used during session establishment, an ephemeral key
exchange can also be used to enhance forward secrecy. If the exchange can also be used to enhance forward secrecy. If the
original key exchange was hybrid, should an ephemeral key exchange in original key exchange was hybrid, should an ephemeral key exchange in
a resumption of that original key exchange be required to use the a resumption of that original key exchange be required to use the
same hybrid algorithms? same hybrid algorithms?
5.3. Failures 6.3. Failures
Some post-quantum key exchange algorithms have non-trivial failure Some post-quantum key exchange algorithms have non-trivial failure
rates: two honest parties may fail to agree on the same shared secret rates: two honest parties may fail to agree on the same shared secret
with non-negligible probability. Does a non-negligible failure rate with non-negligible probability. Does a non-negligible failure rate
affect the security of TLS? How should such a failure be treated affect the security of TLS? How should such a failure be treated
operationally? What is an acceptable failure rate? operationally? What is an acceptable failure rate?
6. Acknowledgements 7. Acknowledgements
These ideas have grown from discussions with many colleagues, These ideas have grown from discussions with many colleagues,
including Christopher Wood, Matt Campagna, and authors of the various including Christopher Wood, Matt Campagna, and authors of the various
hybrid Internet-Drafts and implementations cited in this document. hybrid Internet-Drafts and implementations cited in this document.
The immediate impetus for this document came from discussions with The immediate impetus for this document came from discussions with
attendees at the Workshop on Post-Quantum Software in Mountain View, attendees at the Workshop on Post-Quantum Software in Mountain View,
California, in January 2019. California, in January 2019.
7. References Martin Thomson suggested the (Comb-KDF-1) (Section 3.4.2) approach.
7.1. Normative References 8. References
8.1. Normative References
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
7.2. Informative References 8.2. Informative References
[BCNS15] Bos, J., Costello, C., Naehrig, M., and D. Stebila, "Post- [BCNS15] Bos, J., Costello, C., Naehrig, M., and D. Stebila, "Post-
Quantum Key Exchange for the TLS Protocol from the Ring Quantum Key Exchange for the TLS Protocol from the Ring
Learning with Errors Problem", 2015 IEEE Symposium on Learning with Errors Problem", 2015 IEEE Symposium on
Security and Privacy, DOI 10.1109/sp.2015.40, May 2015. Security and Privacy, DOI 10.1109/sp.2015.40, May 2015.
[BERNSTEIN] [BERNSTEIN]
"Post-Quantum Cryptography", Springer Berlin "Post-Quantum Cryptography", Springer Berlin
Heidelberg book, DOI 10.1007/978-3-540-88702-7, 2009. Heidelberg book, DOI 10.1007/978-3-540-88702-7, 2009.
skipping to change at page 20, line 45 skipping to change at page 30, line 22
<https://www.etsi.org/images/files/ETSIWhitePapers/ <https://www.etsi.org/images/files/ETSIWhitePapers/
QuantumSafeWhitepaper.pdf>. QuantumSafeWhitepaper.pdf>.
[EVEN] Even, S. and O. Goldreich, "On the Power of Cascade [EVEN] Even, S. and O. Goldreich, "On the Power of Cascade
Ciphers", Advances in Cryptology pp. 43-50, Ciphers", Advances in Cryptology pp. 43-50,
DOI 10.1007/978-1-4684-4730-9_4, 1984. DOI 10.1007/978-1-4684-4730-9_4, 1984.
[EXTERN-PSK] [EXTERN-PSK]
Housley, R., "TLS 1.3 Extension for Certificate-based Housley, R., "TLS 1.3 Extension for Certificate-based
Authentication with an External Pre-Shared Key", draft- Authentication with an External Pre-Shared Key", draft-
ietf-tls-tls13-cert-with-extern-psk-00 (work in progress), ietf-tls-tls13-cert-with-extern-psk-02 (work in progress),
February 2019. May 2019.
[FRODO] Bos, J., Costello, C., Ducas, L., Mironov, I., Naehrig, [FRODO] Bos, J., Costello, C., Ducas, L., Mironov, I., Naehrig,
M., Nikolaenko, V., Raghunathan, A., and D. Stebila, M., Nikolaenko, V., Raghunathan, A., and D. Stebila,
"Frodo", Proceedings of the 2016 ACM SIGSAC Conference on "Frodo", Proceedings of the 2016 ACM SIGSAC Conference on
Computer and Communications Security - CCS'16, Computer and Communications Security - CCS'16,
DOI 10.1145/2976749.2978425, 2016. DOI 10.1145/2976749.2978425, 2016.
[GIACON] Giacon, F., Heuer, F., and B. Poettering, "KEM Combiners", [GIACON] Giacon, F., Heuer, F., and B. Poettering, "KEM Combiners",
Public-Key Cryptography - PKC 2018 pp. 190-218, Public-Key Cryptography - PKC 2018 pp. 190-218,
DOI 10.1007/978-3-319-76578-5_7, 2018. DOI 10.1007/978-3-319-76578-5_7, 2018.
[HARNIK] Harnik, D., Kilian, J., Naor, M., Reingold, O., and A. [HARNIK] Harnik, D., Kilian, J., Naor, M., Reingold, O., and A.
Rosen, "On Robust Combiners for Oblivious Transfer and Rosen, "On Robust Combiners for Oblivious Transfer and
Other Primitives", Lecture Notes in Computer Science pp. Other Primitives", Lecture Notes in Computer Science pp.
96-113, DOI 10.1007/11426639_6, 2005. 96-113, DOI 10.1007/11426639_6, 2005.
[HOFFMAN] Hoffman, P., "The Transition from Classical to Post- [HOFFMAN] Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", draft-hoffman-c2pq-04 (work in Quantum Cryptography", draft-hoffman-c2pq-05 (work in
progress), August 2018. progress), May 2019.
[IKE-HYBRID] [IKE-HYBRID]
Tjhai, C., Tomlinson, M., grbartle@cisco.com, g., Fluhrer, Tjhai, C., Tomlinson, M., grbartle@cisco.com, g., Fluhrer,
S., Geest, D., Garcia-Morchon, O., and V. Smyslov, S., Geest, D., Garcia-Morchon, O., and V. Smyslov,
"Framework to Integrate Post-quantum Key Exchanges into "Framework to Integrate Post-quantum Key Exchanges into
Internet Key Exchange Protocol Version 2 (IKEv2)", draft- Internet Key Exchange Protocol Version 2 (IKEv2)", draft-
tjhai-ipsecme-hybrid-qske-ikev2-03 (work in progress), tjhai-ipsecme-hybrid-qske-ikev2-03 (work in progress),
January 2019. January 2019.
[IKE-PSK] Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov, [IKE-PSK] Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov,
"Postquantum Preshared Keys for IKEv2", draft-ietf- "Postquantum Preshared Keys for IKEv2", draft-ietf-
ipsecme-qr-ikev2-07 (work in progress), January 2019. ipsecme-qr-ikev2-08 (work in progress), March 2019.
[KIEFER] Kiefer, F. and K. Kwiatkowski, "Hybrid ECDHE-SIDH Key [KIEFER] Kiefer, F. and K. Kwiatkowski, "Hybrid ECDHE-SIDH Key
Exchange for TLS", draft-kiefer-tls-ecdhe-sidh-00 (work in Exchange for TLS", draft-kiefer-tls-ecdhe-sidh-00 (work in
progress), November 2018. progress), November 2018.
[KPW13] Krawczyk, H., Paterson, K., and H. Wee, "On the Security [KPW13] Krawczyk, H., Paterson, K., and H. Wee, "On the Security
of the TLS Protocol: A Systematic Analysis", Advances in of the TLS Protocol: A Systematic Analysis", Advances in
Cryptology - CRYPTO 2013 pp. 429-448, Cryptology - CRYPTO 2013 pp. 429-448,
DOI 10.1007/978-3-642-40041-4_24, 2013. DOI 10.1007/978-3-642-40041-4_24, 2013.
skipping to change at page 21, line 50 skipping to change at page 31, line 29
2018, <https://www.imperialviolet.org/2018/04/11/ 2018, <https://www.imperialviolet.org/2018/04/11/
pqconftls.html>. pqconftls.html>.
[NIELSEN] Nielsen, M. and I. Chuang, "Quantum Computation and [NIELSEN] Nielsen, M. and I. Chuang, "Quantum Computation and
Quantum Information", Cambridge University Press , 2000. Quantum Information", Cambridge University Press , 2000.
[NIST] National Institute of Standards and Technology (NIST), [NIST] National Institute of Standards and Technology (NIST),
"Post-Quantum Cryptography", n.d., "Post-Quantum Cryptography", n.d.,
<https://www.nist.gov/pqcrypto>. <https://www.nist.gov/pqcrypto>.
[NIST-SP-800-135]
National Institute of Standards and Technology (NIST),
"Recommendation for Existing Application-Specific Key
Derivation Functions", December 2011,
<https://doi.org/10.6028/NIST.SP.800-135r1>.
[NIST-SP-800-56C]
National Institute of Standards and Technology (NIST),
"Recommendation for Key-Derivation Methods in Key-
Establishment Schemes", April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Cr1>.
[OQS-102] Open Quantum Safe Project, "OQS-OpenSSL-1-0-2_stable", [OQS-102] Open Quantum Safe Project, "OQS-OpenSSL-1-0-2_stable",
November 2018, <https://github.com/open-quantum- November 2018, <https://github.com/open-quantum-
safe/openssl/tree/OQS-OpenSSL_1_0_2-stable>. safe/openssl/tree/OQS-OpenSSL_1_0_2-stable>.
[OQS-111] Open Quantum Safe Project, "OQS-OpenSSL-1-1-1_stable", [OQS-111] Open Quantum Safe Project, "OQS-OpenSSL-1-1-1_stable",
November 2018, <https://github.com/open-quantum- November 2018, <https://github.com/open-quantum-
safe/openssl/tree/OQS-OpenSSL_1_1_1-stable>. safe/openssl/tree/OQS-OpenSSL_1_1_1-stable>.
[SCHANCK] Schanck, J. and D. Stebila, "A Transport Layer Security [SCHANCK] Schanck, J. and D. Stebila, "A Transport Layer Security
(TLS) Extension For Establishing An Additional Shared (TLS) Extension For Establishing An Additional Shared
skipping to change at page 22, line 36 skipping to change at page 32, line 27
RFC 8391, DOI 10.17487/RFC8391, May 2018, RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/info/rfc8391>. <https://www.rfc-editor.org/info/rfc8391>.
[ZHANG] Zhang, R., Hanaoka, G., Shikata, J., and H. Imai, "On the [ZHANG] Zhang, R., Hanaoka, G., Shikata, J., and H. Imai, "On the
Security of Multiple Encryption or CCA-security+CCA- Security of Multiple Encryption or CCA-security+CCA-
security=CCA-security?", Public Key Cryptography - PKC security=CCA-security?", Public Key Cryptography - PKC
2004 pp. 360-374, DOI 10.1007/978-3-540-24632-9_26, 2004. 2004 pp. 360-374, DOI 10.1007/978-3-540-24632-9_26, 2004.
Authors' Addresses Authors' Addresses
Douglas Steblia Douglas Stebila
University of Waterloo University of Waterloo
Email: dstebila@uwaterloo.ca Email: dstebila@uwaterloo.ca
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Shay Gueron Shay Gueron
University of Haifa and Amazon Web Services University of Haifa and Amazon Web Services
Email: shay.gueron@gmail.com Email: shay.gueron@gmail.com
 End of changes. 51 change blocks. 
92 lines changed or deleted 543 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/