< draft-campagna-tls-bike-sike-hybrid-00.txt   draft-campagna-tls-bike-sike-hybrid-01.txt >
Internet Engineering Task Force M. Campagna Internet Engineering Task Force M. Campagna
Internet-Draft E. Crockett Internet-Draft E. Crockett
Intended status: Experimental AWS Intended status: Experimental AWS
Expires: September 28, 2019 March 27, 2019 Expires: November 8, 2019 May 7, 2019
BIKE and SIKE Hybrid Key Exchange Cipher Suites for Transport Layer Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport
Security (TLS) Layer Security 1.2 (TLS)
draft-campagna-tls-bike-sike-hybrid-00 draft-campagna-tls-bike-sike-hybrid-01
Abstract Abstract
This document describes new hybrid key exchange schemes for the Hybrid key exchange refers to executing two independent key exchanges
Transport Layer Security (TLS) protocol, which are based on combining and feeding the two resulting shared secrets into a Pseudo Random
Elliptic Curve Diffie Hellman (ECDH) with one of the Bit Flipping Key Function (PRF), with the goal of deriving a secret which is as secure
Exchange (BIKE) or the Supersingular Isogeny Key Exchange (SIKE) as the stronger of the two key exchanges. This document describes
schemes. In particular, this document specifies the use of BIKE or new hybrid key exchange schemes for the Transport Layer Security 1.2
SIKE in combination with ECDHE as a hybrid key agreement in a TLS 1.2 (TLS) protocol. The key exchange schemes are based on combining
handshake, together with the use of ECDSA or RSA for authentication. Elliptic Curve Diffie-Hellman (ECDH) with a post-quantum key
Hybrid key exchange refers to executing two separate key exchanges encapsulation method (PQ KEM) using the existing TLS PRF. In
and subsequently feeding the two resulting shared secrets into the particular, this document specifies the use of the Bit Flipping Key
existing TLS Pseudo Random Function (PRF), in order to derive a Exchange (BIKE) and Supersingular Isogeny Key Exchange (SIKE) schemes
master secret. in combination with ECDHE as a hybrid key agreement in a TLS 1.2
handshake.
Context Context
This draft is experimental. It is intended to define hybrid key This draft is experimental. It is intended to define hybrid key
exchanges in sufficient detail to allow independent experimentations exchanges in sufficient detail to allow independent experimentations
to interoperate. While the NIST standardization process is still a to interoperate. While the NIST standardization process is still a
few years away from being complete, we know that many TLS users have few years away from being complete, we know that many TLS users have
highly sensitive workloads that would benefit from the speculative highly sensitive workloads that would benefit from the speculative
additional protections provided by quantum-safe key exchanges. These additional protections provided by quantum-safe key exchanges. These
key exchanges are likely to change through the standardization key exchanges are likely to change through the standardization
skipping to change at page 2, line 12 skipping to change at page 2, line 15
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 28, 2019. This Internet-Draft will expire on November 8, 2019.
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
skipping to change at page 2, line 35 skipping to change at page 2, line 38
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. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 4
2.1. Key Encapsulation Method (KEM) . . . . . . . . . . . . . 5 2.1. Key Encapsulation Method (KEM) . . . . . . . . . . . . . 5
2.2. ECDHE_BIKE_[SIG] . . . . . . . . . . . . . . . . . . . . 6 2.2. ECDHE_[KEM] . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. ECDHE_SIKE_[SIG] . . . . . . . . . . . . . . . . . . . . 6 3. Hybrid Premaster Secret . . . . . . . . . . . . . . . . . . . 6
3. Hybrid Premaster Secret . . . . . . . . . . . . . . . . . . . 7 4. TLS Extension for Supported PQ KEM Parameters . . . . . . . . 7
3.1. Concatenated premaster secret . . . . . . . . . . . . . . 7 5. Data Structures and Computations . . . . . . . . . . . . . . 7
4. TLS Extensions for BIKE and SIKE . . . . . . . . . . . . . . 7
5. Data Structures and Computations . . . . . . . . . . . . . . 8
5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8
5.1.1. When these extensions are sent . . . . . . . . . . . 8 5.1.1. When these extensions are sent . . . . . . . . . . . 8
5.1.2. Meaning of these extensions . . . . . . . . . . . . . 8 5.1.2. Meaning of these extensions . . . . . . . . . . . . . 8
5.1.3. Structure of these extensions . . . . . . . . . . . . 8 5.1.3. Structure of these extensions . . . . . . . . . . . . 8
5.1.4. Actions of the sender . . . . . . . . . . . . . . . . 9 5.1.4. Actions of the sender . . . . . . . . . . . . . . . . 8
5.1.5. Actions of the receiver . . . . . . . . . . . . . . . 9 5.1.5. Actions of the receiver . . . . . . . . . . . . . . . 8
5.1.6. Supported BIKE Parameter Extension . . . . . . . . . 9 5.1.6. Supported PQ KEM Parameters Extension . . . . . . . . 9
5.1.7. Supported SIKE Parameter Extension . . . . . . . . . 10 5.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 10
5.2. Server Key Exchange . . . . . . . . . . . . . . . . . . . 11 5.2.1. When this message is sent . . . . . . . . . . . . . . 10
5.2.1. When this message is sent . . . . . . . . . . . . . . 11 5.2.2. Meaning of this message . . . . . . . . . . . . . . . 10
5.2.2. Meaning of this message . . . . . . . . . . . . . . . 11 5.2.3. Structure of this message . . . . . . . . . . . . . . 10
5.2.3. Structure of this message . . . . . . . . . . . . . . 11 5.2.4. Actions of the sender . . . . . . . . . . . . . . . . 11
5.2.4. Actions of the sender . . . . . . . . . . . . . . . . 13 5.2.5. Actions of the receiver . . . . . . . . . . . . . . . 12
5.2.5. Actions of the receiver . . . . . . . . . . . . . . . 13 5.3. Client Key Exchange . . . . . . . . . . . . . . . . . . . 12
5.3. Client Key Exchange . . . . . . . . . . . . . . . . . . . 13 5.3.1. When this message is sent . . . . . . . . . . . . . . 12
5.3.1. When this message is sent . . . . . . . . . . . . . . 13 5.3.2. Meaning of the message . . . . . . . . . . . . . . . 12
5.3.2. Meaning of the message . . . . . . . . . . . . . . . 13 5.3.3. Structure of this message . . . . . . . . . . . . . . 12
5.3.3. Structure of this message . . . . . . . . . . . . . . 14 5.3.4. Actions of the sender . . . . . . . . . . . . . . . . 13
5.3.4. Actions of the sender . . . . . . . . . . . . . . . . 14 5.3.5. Actions of the receiver . . . . . . . . . . . . . . . 13
5.3.5. Actions of the receiver . . . . . . . . . . . . . . . 15 5.4. Derivation of the master secret for hybrid key agreement 13
5.4. Derivation of the master secret for hybrid key agreement 15 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations [DRAFT] . . . . . . . . . . . . . . . 15
7. Security Considerations [DRAFT] . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Normative References . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Quantum-safe (or post-quantum) key exchanges are being developed in Quantum-safe (or post-quantum) key exchanges are being developed in
order to provide secure key establishment against an adversary with order to provide secure key establishment against an adversary with
access to a quantum computer. Under such a threat model, the current access to a quantum computer. Under such a threat model, the current
key exchange mechanisms would be vulnerable. BIKE and SIKE are two key exchange mechanisms would be vulnerable. BIKE and SIKE are two
such schemes which were submitted to the NIST Call for Proposals for post-quantum candidates which were submitted to the NIST Call for
Post Quantum Cryptographic Schemes. While these schemes are still Proposals for Post-Quantum Cryptographic Schemes. While these
being analyzed as part of that process, there is already a need to schemes are still being analyzed as part of that process, there is
protect the confidentiality of today's TLS connections against a already a need to protect the confidentiality of today's TLS
future adversary with a quantum computer. Hybrid key exchanges are connections against a future adversary with a quantum computer.
designed to provide two parallel key exchanges: one which is Hybrid key exchanges are designed to provide two parallel key
classical (e.g., ECDHE) and the other which is quantum-safe (e.g., exchanges: one which is classical (e.g., ECDHE) and the other which
BIKE or SIKE). This strategy is emerging as a method to is quantum-safe (e.g., BIKE or SIKE). The hybrid schemes we propose
speculatively provide additional security to existing protocols. are no less secure against classical computers than ECDH, and no less
secure against quantum computers than BIKE or SIKE. This strategy is
emerging as a method to speculatively provide additional security to
existing protocols.
This document describes additions to TLS to support BIKE and SIKE This document describes additions to TLS to support PQ Hybrid Key
Hybrid Key Exchanges, applicable to TLS Version 1.2 [RFC5246]. In Exchanges, applicable to TLS Version 1.2 [RFC5246]. These additions
particular, it defines the use of the ECDH together with BIKE or are designed to support most of the second-round candidates in the
NIST Call for Proposals, but this document only defines ciphersuites
for a small subset of possible hybrid key agreement methods. In
particular, it defines the use of the ECDHE together with BIKE or
SIKE, as a hybrid key agreement method. SIKE, as a hybrid key agreement method.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
provides an overview of BIKE- and SIKE-based key exchange algorithms provides an overview of PQ KEM-based key exchange algorithms for TLS.
for TLS. Section 3 describes how BIKE and SIKE can be combined with Section 3 describes how PQ KEM can be combined with ECDHE to form a
ECDHE to form a premaster secret. TLS extensions that allow a client premaster secret. In Section 4, we present a TLS extension that
to negotiate the use of specific BIKE and SIKE parameters are allow a client to negotiate the use of specific PQ schemes and
presented in Section 4. Section 5 specifies various data structures parameters. Section 5 specifies various data structures needed for a
needed for a BIKE- or SIKE-based hybrid key exchange handshake, their BIKE- or SIKE-based hybrid key exchange handshake, their encoding in
encoding in TLS messages, and the processing of those messages. TLS messages, and the processing of those messages. Section 6
Section 6 defines new BIKE and SIKE hybrid-based cipher suites and defines two new PQ KEM hybrid-based cipher suites and identifies a
identifies a small subset of these as recommended for all small subset of these as recommended for all implementations of this
implementations of this specification. Section 7 discusses some specification. Section 7 discusses some security considerations.
security considerations. Section 8 describes IANA considerations for Section 8 describes IANA considerations for the name spaces created
the name spaces created by this document. Section 9 gives by this document. Section 9 gives acknowledgments.
acknowledgments.
Implementation of this specification requires familiarity with TLS Implementation of this specification requires familiarity with TLS
[RFC5246], TLS extensions [RFC6066], BIKE, and SIKE. [RFC5246], BIKE, and SIKE.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Key Exchange Algorithms 2. Key Exchange Algorithms
This document introduces two new hybrid-based key exchange methods This document introduces two new hybrid-based key exchange methods
for TLS. They use ECDHE with either BIKE or SIKE, in order to for TLS. They use ECDHE with either BIKE or SIKE in order to compute
compute the TLS premaster secret. The master secret derivation is the TLS premaster secret. The master secret derivation is augmented
augmented to include the ClientKeyExchange message. The derivation to include the ClientKeyExchange message. The derivation of the
of the encryption/MAC keys and initialization vectors is independent encryption/MAC keys and initialization vectors is independent of the
of the key exchange algorithm and not impacted by the introduction of key exchange algorithm and not impacted by the introduction of these
these hybrid key exchanges. hybrid key exchanges. While this specification only defines the use
of a PQ KEM hybrid key exchange with BIKE or SIKE, it is specifically
designed so that it can be easily extended to include additional PQ
KEM methods.
The table below summarizes the new hybrid key exchange schemes. The table below summarizes the new hybrid key exchange schemes.
+-------------------------------+-----------------------------------+ +---------------------------------+-----------------------+
| Hybrid Key Exchange Scheme | Description | | Hybrid Key Exchange Scheme Name | Description |
| Name | | +---------------------------------+-----------------------+
+-------------------------------+-----------------------------------+ | ECDHE_BIKE | ECDHE and a BIKE KEM. |
| ECDHE_BIKE_RSA | ECDHE and BIKE with RSA | | | |
| | signatures. | | ECDHE_SIKE | ECDHE and a SIKE KEM. |
| | | +---------------------------------+-----------------------+
| ECDHE_BIKE_ECDSA | ECDHE and BIKE with ECDSA |
| | signatures. |
| | |
| ECDHE_SIKE_RSA | ECDHE and SIKE with RSA |
| | signatures. |
| | |
| ECDHE_SIKE_ECDSA | ECDHE and SIKE with ECDSA |
| | signatures. |
+-------------------------------+-----------------------------------+
Table 1: BIKE and SIKE Hybrid Key Exchange Schemes Table 1: Hybrid Key Exchange Schemes
These schemes are intended to provide quantum-safe forward secrecy. These schemes are intended to provide quantum-safe forward secrecy.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate Certificate
ServerKeyExchange ServerKeyExchange
skipping to change at page 5, line 36 skipping to change at page 5, line 36
is desired is desired
Figure 1: Message flow in a hybrid TLS handshake Figure 1: Message flow in a hybrid TLS handshake
Figure 1 shows the messages involved in the TLS key establishment Figure 1 shows the messages involved in the TLS key establishment
protocol (aka full handshake). The addition of hybrid key exchanges protocol (aka full handshake). The addition of hybrid key exchanges
has direct impact on the ClientHello, the ServerHello, the has direct impact on the ClientHello, the ServerHello, the
ServerKeyExchange, and the ClientKeyExchange messages. Next, we ServerKeyExchange, and the ClientKeyExchange messages. Next, we
describe each hybrid key exchange scheme in greater detail in terms describe each hybrid key exchange scheme in greater detail in terms
of the content and processing of these messages. For ease of of the content and processing of these messages. For ease of
exposition, we defer discussion of the optional BIKE- and SIKE- exposition, we defer discussion of the optional extension for
specific extensions (which impact the Hello messages) until specifying the parameters supported by an implementation until
Section 4. Section 4.
2.1. Key Encapsulation Method (KEM) 2.1. Key Encapsulation Method (KEM)
A key encapsulation mechanism (KEM) is a set of three algorithms A key encapsulation mechanism (KEM) is a set of three algorithms
o key generation (KeyGen) o key generation (KeyGen)
o encapsulation (Encaps) o encapsulation (Encaps)
skipping to change at page 6, line 14 skipping to change at page 6, line 14
o "Encaps(pk)": takes pk as input and outputs ciphertext c and a key o "Encaps(pk)": takes pk as input and outputs ciphertext c and a key
K from the key space. K from the key space.
o "Decaps(sk, c)": takes sk and c as input, and returns a key K or o "Decaps(sk, c)": takes sk and c as input, and returns a key K or
ERROR. K is called the session key. ERROR. K is called the session key.
The security of a KEM is discussed in Section 7. BIKE and SIKE are The security of a KEM is discussed in Section 7. BIKE and SIKE are
two examples of a KEM. two examples of a KEM.
2.2. ECDHE_BIKE_[SIG] 2.2. ECDHE_[KEM]
This section describes the two nearly identical hybrid key exchanges This section describes the nearly identical hybrid key exchanges
ECDHE_BIKE_RSA and ECDHE_BIKE_ECDSA. For the remainder of this ECDHE_BIKE and ECDHE_SIKE. For the remainder of this section [KEM]
section SIG refers to either RSA or ECDSA. The server sends its refers to either BIKE or SIKE. The server sends its ephemeral ECDH
ephemeral ECDH public key and ephemeral BIKE public key generated public key and an ephemeral [KEM] public key generated using the
using the BIKE Key Encapsulation Method (KEM) and a specification of corresponding curve and [KEM] parameters in the ServerKeyExchange
the corresponding curve and BIKE parameters in the ServerKeyExchange message. This specification requires that these parameters MUST be
message. These parameters MUST be signed with the signature signed using a signature algorithm corresponding to the public key in
algorithm SIG using the private key corresponding to the public key the server's certificate.
in the server's certificate.
The client generates an ECDHE key pair on the same curve as the The client generates an ECDHE key pair on the same curve as the
server's ephemeral ECDH key, and computes a ciphertext value based on server's ephemeral ECDH key, and computes a ciphertext value based on
the BIKE public key provided by the server, and sends them in the the [KEM] public key provided by the server, and sends them in the
ClientKeyExchange message. The client computes and holds the BIKE- ClientKeyExchange message. The client computes and holds the PQ KEM-
encapsulated key (K) as a contribution to the premaster secret. encapsulated key (K) as a contribution to the premaster secret.
Both client and server perform an ECDH operation and use the Both client and server perform an ECDH operation and use the
resultant shared secret (Z) as part of the premaster secret. The resultant shared secret (Z) as part of the premaster secret. The
server computes the BIKE decapsulation routine to compute the server computes the PQ KEM decapsulation routine to compute the
encapsulated key (K), or to produce an error message in case the encapsulated key (K), or to produce an error message in case the
decapsulation fails. decapsulation fails.
2.3. ECDHE_SIKE_[SIG]
This section describes the two nearly identical hybrid key exchanges
ECDHE_SIKE_RSA and ECDHE_SIKE_ECDSA. For the remainder of this
section SIG refers to either RSA or ECDSA. ECDHE_SIKE_[SIG] is
nearly identical to ECDHE_BIKE_[SIG]. The server sends its ephemeral
ECDH public key and ephemeral SIKE public key generated using the
SIKE Key Encapsulation Method (KEM) and a specification of the
corresponding ECDH curve and SIKE parameters in the ServerKeyExchange
message. These parameters MUST be signed with the signature
algorithm SIG using the private key corresponding to the public key
in the server's certificate.
3. Hybrid Premaster Secret 3. Hybrid Premaster Secret
This section defines new hybrid key exchanges for TLS 1.2 [RFC5246]. This section defines the mechanism for combining the ECDHE and [KEM]
Here, both the server and the client compute two shared secrets: the secrets into a TLS 1.2 [RFC5246] pre-master secret. In the hybrid
previously defined ECDHE shared secret Z from RFC 6066, and another key exchange, both the server and the client compute two shared
shared secret K from the underlying BIKE or SIKE key encapsulation secrets: the previously defined ECDHE shared secret Z from RFC 8422,
and another shared secret K from the underlying PQ key encapsulation
method. method.
To simplify the text when we speak about BIKE or SIKE interchangeably Form the premaster secret for ECDHE_[KEM] hybrid key exchanges as the
we will simply denote this as [KEM]. concatenation of the ECDHE shared secret Z with the KEM key K to form
the opaque data value "premaster_secret = Z || K".
3.1. Concatenated premaster secret
Form the premaster secret for ECDHE_[KEM]_[SIG] hybrid key exchanges
as the concatenation of the ECDHE shared secret Z with the KEM key K
to form the opaque data value "premaster_secret = Z || K".
4. TLS Extensions for BIKE and SIKE
Two new TLS extensions are defined in this specification:
1. the Supported BIKE Parameters Extension, and 4. TLS Extension for Supported PQ KEM Parameters
2. the Supported SIKE Parameters Extension. A new TLS extension for post-quantum key encapsulation methods is
defined in this specification.
These allow negotiating the use of specific [KEM] parameter sets This allows negotiating the use of specific PQ KEM parameter sets
during a handshake starting a new session. These extensions are during a handshake starting a new session. The extension is
especially relevant for constrained clients that may only support a especially relevant for constrained clients that may only support a
limited number of [KEM] parameter sets. They follow the general limited number of PQ KEM parameter sets. They follow the general
approach outlined in RFC 6066; message details are specified in approach outlined in RFC 5246; message details are specified in
Section 5. The client enumerates the BIKE and SIKE parameters it Section 5. The client enumerates the BIKE and SIKE parameters it
supports by including the appropriate extensions in its ClientHello supports by including the PQ KEM extension in its ClientHello
message. message.
A TLS client that proposes [KEM] cipher suites in its ClientHello A TLS client that proposes PQ KEM cipher suites in its ClientHello
message SHOULD include these extensions. Servers implementing a message SHOULD include this extension. Servers implementing a PQ KEM
[KEM] cipher suite MUST support these extensions, and when a client cipher suite MUST support this extension, and when a client uses this
uses these extensions, servers MUST NOT negotiate the use of a [KEM] extension, servers MUST NOT negotiate the use of a PQ KEM parameter
parameter set unless they can complete the handshake while respecting set unless they can complete the handshake while respecting the
the choice of parameters specified by the client. This eliminates choice of parameters specified by the client. This eliminates the
the possibility that a negotiated hybrid handshake will be possibility that a negotiated hybrid handshake will be subsequently
subsequently aborted due to a client's inability to deal with the aborted due to a client's inability to deal with the server's PQ KEM
server's [KEM] key. key.
The client MUST NOT include these extensions in the ClientHello The client MUST NOT include the PQ KEM extension in the ClientHello
message if it does not propose any [KEM] cipher suites. That is, if message if it does not propose any PQ KEM cipher suites.
Additionally, the client MUST NOT include parameters in the PQ KEM
extension for PQ KEM cipher suites it does not propose. That is, if
a client does not support BIKE, it must not include the BIKE a client does not support BIKE, it must not include the BIKE
parameters extension, and if the client does not support SIKE, it parameters in the extension, and if the client does not support SIKE,
must not include the SIKE parameter extension. A client that it must not include SIKE parameters in the extension. A client that
proposes a [KEM] scheme may choose not to include these extensions. proposes a PQ KEM scheme may choose not to include this extension.
In this case, the server is free to choose any one of the parameter In this case, the server is free to choose any one of the parameter
sets listed in Section 5. That section also describes the structure sets listed in Section 5. That section also describes the structure
and processing of these extensions in greater detail. and processing of this extension in greater detail.
In the case of session resumption, the server simply ignores the In the case of session resumption, the server simply ignores the
Supported [KEM] Parameter Extension appearing in the current Supported PQ KEM Parameters extension appearing in the current
ClientHello message. These extensions only play a role during ClientHello message. These extensions only play a role during
handshakes negotiating a new session. handshakes negotiating a new session.
5. Data Structures and Computations 5. Data Structures and Computations
This section specifies the data structures and computations used by This section specifies the data structures and computations used by
[KEM] hybrid-key agreement mechanisms specified in Sections 2, 3, and PQ KEM hybrid-key agreement mechanisms specified in Sections 2, 3,
4. The presentation language used here is the same as that used in and 4. The presentation language used here is the same as that used
TLS 1.2 [RFC5246]. in TLS 1.2 [RFC5246].
5.1. Client Hello Extensions 5.1. Client Hello Extensions
This section specifies two TLS extensions that can be included with This section specifies the Supported PQ KEM Parameters extension that
the ClientHello message as described in RFC 6066, and the Supported can be included with the ClientHello message as described in
[KEM] Parameters Extension. RFC 5246.
5.1.1. When these extensions are sent 5.1.1. When these extensions are sent
The extensions SHOULD be sent along with any ClientHello message that The extensions SHOULD be sent along with any ClientHello message that
proposes the associated [KEM] cipher suites. proposes the associated PQ KEM cipher suites.
5.1.2. Meaning of these extensions 5.1.2. Meaning of these extensions
These extensions allow a client to enumerate the BIKE or SIKE These extensions allow a client to enumerate the PQ KEM parameters
parameters sets it supports. sets it supports for any supported PQ KEM.
5.1.3. Structure of these extensions 5.1.3. Structure of these extensions
The general structure of TLS extensions is described in RFC 6066, and The general structure of TLS extensions is described in RFC 5246, and
this specification adds two new types to ExtensionType. this specification adds a new type to ExtensionType.
enum { enum {
bike_parameters(0xFE01), pq_kem_parameters(0xFE01)
sike_parameters(0xFE02)
} ExtensionType; } ExtensionType;
where where
o "bike_parameters" (Supported BIKE Parameters Extension): Indicates o "pq_kem_parameters" (Supported PQ KEM Parameters extension):
the set of BIKE parameters supported by the client. For this Indicates the set of post-quantum KEM parameters supported by the
extension, the opaque extension_data field contains client. For this extension, the opaque extension_data field
BIKEParameterList. See Section 5.1.6 for details. contains PQKEMParametersExtension. See Section 5.1.6 for details.
o "sike_parameters" (Supported SIKE Parameters Extension): Indicates
the set of SIKE parameters supported by the client. For this
extension, the opaque extension_data field contains
SIKEParameterList. See Section 5.1.7 for details.
5.1.4. Actions of the sender 5.1.4. Actions of the sender
A client that proposes a [KEM] hybrid key exchange cipher suites in A client that proposes PQ KEM hybrid key exchange cipher suites in
its ClientHello message appends these extensions (along with any its ClientHello message appends these extensions (along with any
others), enumerating the parameters it supports. Clients SHOULD send others), enumerating the parameters it supports. Clients SHOULD send
the Supported BIKE Parameters Extension if it supports a BIKE hybrid the PQ KEM parameter sets it supports if it supports PQ KEM hybrid
key exchange cipher suite, and it SHOULD send the Supported SIKE key exchange cipher suites.
Parameters Extension if it supports a SIKE hybrid key exchange cipher
suite.
5.1.5. Actions of the receiver 5.1.5. Actions of the receiver
A server that receives a ClientHello containing one or both of these A server that receives a ClientHello containing this extension MUST
extensions MUST use the client's enumerated capabilities to guide its use the client's enumerated capabilities to guide its selection of an
selection of an appropriate cipher suite. One of the proposed [KEM] appropriate cipher suite. One of the proposed PQ KEM cipher suites
cipher suites must be negotiated only if the server can successfully must be negotiated only if the server can successfully complete the
complete the handshake while using the [KEM] parameters supported by handshake while using the PQ KEM parameters supported by the client
the client (cf. Section 5.1.6 and Section 5.1.7.) (cf. Section 5.1.6.)
If a server does not understand the Supported PQ KEM Parameters
If a server does not understand the Supported [KEM] Parameters extension, or is unable to complete the PQ KEM handshake while
Extension, or is unable to complete the [KEM] handshake while
restricting itself to the enumerated parameters, it MUST NOT restricting itself to the enumerated parameters, it MUST NOT
negotiate the use of the corresponding [KEM] cipher suite. Depending negotiate the use of the corresponding PQ KEM cipher suite.
on what other cipher suites are proposed by the client and supported Depending on what other cipher suites are proposed by the client and
by the server, this may result in a fatal handshake failure alert due supported by the server, this may result in a fatal handshake failure
to the lack of common cipher suites. alert due to the lack of common cipher suites.
5.1.6. Supported BIKE Parameter Extension 5.1.6. Supported PQ KEM Parameters Extension
This section defines the contents of the Supported PQ KEM Parameters
extension. In the language of RFC 5246, the "extension_data" is the
"PQKEMParametersExtension" type defined below.
enum { enum {
BIKE1r1-Level1 (1), BIKE1r1-Level1 (1),
BIKE1r1-Level3 (2), BIKE1r1-Level3 (2),
BIKE1r1-Level5 (3), BIKE1r1-Level5 (3),
BIKE2r1-Level1 (4), BIKE2r1-Level1 (4),
BIKE2r1-Level3 (5), BIKE2r1-Level3 (5),
BIKE2r1-Level5 (6), BIKE2r1-Level5 (6),
BIKE3r1-Level1 (7), BIKE3r1-Level1 (7),
BIKE3r1-Level3 (8), BIKE3r1-Level3 (8),
BIKE3r1-Level5 (9) BIKE3r1-Level5 (9),
} NamedBIKEKEM (2^8-1); SIKEp503r1-KEM (10),
SIKEp751r1-KEM (11),
SIKEp964r1-KEM (12),
} NamedPQKEM (2^16-1);
"BIKE1r1-Level1", etc: Indicates support of the corresponding BIKE "BIKE1r1-Level1", etc: Indicates support of the corresponding BIKE
parameters defined in BIKE, the round 1 candidate to the NIST Post parameters defined in BIKE, the round 1 candidate to the NIST Post-
Quantum Cryptography Standardization Process. Quantum Cryptography Standardization Process.
struct {
NamedBIKEKEM bike_parameter_list <1..2^8-1>
} BIKEParameterList;
Items in "bike_parameter_list" are ordered according to the client's
preferences (favorite choice first).
As an example, a client that only supports BIKE1r1-Level1 ( value 1 =
0x01) and BIKE2-Level1 ( value 4 = 0x04) and prefers to use
BIKE1r1-Level1 would include a TLS extension consisting of the
following octets:
FE 01 00 03 02 01 04
Note that the first two octets indicate the extension type (Supported
BIKE Parameter Extension), the next two octets indicates the length
of the extension (00 03), and the next octet indicates the length of
enumerated values (02).
5.1.7. Supported SIKE Parameter Extension
enum {
SIKEp503r1-KEM (1),
SIKEp751r1-KEM (2),
SIKEp964r1-KEM (3)
} NamedSIKEKEM (2^8-1);
SIKEp503r1-KEM, etc.: Indicates support of the corresponding SIKE SIKEp503r1-KEM, etc.: Indicates support of the corresponding SIKE
parameters defined in SIKE, the round 1 candidate to the NIST Post parameters defined in SIKE, the round 1 candidate to the NIST Post-
Quantum Cryptography Standardization Process. Quantum Cryptography Standardization Process.
struct { struct {
NamedSIKEKEM sike_parameter_list <1,..., 2^8 - 1> NamedPQKEM pq_kem_parameters_list <1..2^16-1>
} SIKEParameterList; } PQKEMParametersExtension;
Items in sike_parameter_list are ordered according to the client's Items in "pq_kem_parameters_list" are ordered according to the
preferences (favorite choice first). client's preferences (favorite choice first).
As an example, a client that only supports SIKEp503r1-KEM ( value 1 = As an example, a client that only supports BIKE1r1-Level1 ( value 1 =
0x01) and SIKEp751r1-KEM ( value 2 = 0x02) and prefers to use 0x0001), BIKE2-Level1 ( value 4 = 0x0004) and SIKEp503r1-KEM ( value
SIKEp503r1-KEM would include a TLS extension consisting of the 10 = 0x000A) and prefers to use SIKEp503r1-KEM would include a TLS
following octets: extension consisting of the following octets:
FE 02 00 03 02 01 02 FE 01 00 08 00 06 00 0A 00 01 00 04
Note that the first two octets indicate the extension type (Supported
SIKE Parameter Extension), the next two octets indicates the length Note that the first two octets (FE 01) indicate the extension type
of the extension (00 03), and the next octet indicates the length of (Supported PQ KEM Parameters extension), the next two octets
enumerated values (02). indicates the length of the extension in bytes (00 08), and the next
two octets indicate the length of enumerated values in bytes (00 06).
5.2. Server Key Exchange 5.2. Server Key Exchange
5.2.1. When this message is sent 5.2.1. When this message is sent
This message is sent when using the ECDHE_[KEM]_ECDSA and This message is sent when using an ECDHE_[KEM] hybrid key exchange
ECDHE_[KEM]_RSA hybrid key exchange algorithms. algorithms.
5.2.2. Meaning of this message 5.2.2. Meaning of this message
This message is used to convey the server's ephemeral ECDH and BIKE This message is used to convey the server's ephemeral ECDH and [KEM]
or SIKE public key to the client. public keys to the client.
5.2.3. Structure of this message 5.2.3. Structure of this message
struct { struct {
opaque public_key <1,...,2^16 - 1>; opaque public_key <1,...,2^24 - 1>;
} BIKEKEMPublicKey; } PQKEMPublicKey;
public_key: This is a byte string representation of the BIKE public
key following the conversion defined by the BIKE implementation.
struct {
NamedBIKEKEM bike_params;
BIKEKEMPublicKey public;
} ServerBIKEKEMParams;
struct {
opaque public_key <1,...,2^16 - 1>;
} SIKEKEMPublicKey;
where
o "public_key": This is a byte string representation of the SIKE public_key: This is a byte string representation of the [KEM] public
public key following the conversion routines of Section 1.2.9 of key following the conversion defined by the [KEM] implementation.
the SIKE specification [SIKE].
struct { struct {
NamedSIKEKEM sike_params; NamedPQKEM named_params;
SIKEKEMPublicKey public; PQKEMPublicKey public;
} ServerSIKEKEMParams; } ServerPQKEMParams;
The ServerKeyExchange message is extended as follows: The ServerKeyExchange message is extended as follows:
enum { struct {
ecdh_bike, ServerECDHParams ecdh_params;
ecdh_sike ServerPQKEMParams pq_kem_params;
} KeyExchangeAlgorithm; Signature signed_params;
"ecdh_bike": Indicates the ServerKeyExchange message contains an ECDH
public key and the server's BIKE parameters. "ecdh_sike": Indicates
the ServerKeyExchange message contains an ECDH public key and the
server's SIKE parameters.
select (KeyExchangeAlgorithm) {
case ecdh_bike:
ServerECDHParams ecdh_params;
ServerBIKEKEMParams bike_params;
Signature signed_params;
case ecdh_sike:
ServerECDHParams ecdh_params;
ServerSIKEKEMParams sike_params;
Signature signed_params;
} ServerKeyExchange; } ServerKeyExchange;
where where
o "ecdh_params": Specifies the ECDH public key and associated domain o "ecdh_params": Specifies the ECDHE public key and associated
parameters. domain parameters.
o "bike_params": Specifies the BIKE public key and associated
parameters.
o "sike_params": Specifies the SIKE public key and associated o "pq_kem_params": Specifies the [KEM] public key and associated
parameters. parameters.
o "signed_params": a signature over the server's key exchange o "signed_params": a signature over the server's key exchange
parameters. The private key corresponding to the certified public parameters. Note that only ciphersuites which include a signature
key in the server's Certificate message is used for signing. algorithm are supported; see Section 6. The private key
corresponding to the certified public key in the server's
Certificate message is used for signing.
digitally-signed struct { digitally-signed struct {
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
ServerDHParams ecdh_params; ServerDHParams ecdh_params;
select (KeyExchangeAlgorithm) { ServerPQKEMParams pq_kem_params;
case ecdh_bike: } Signature;
ServerBIKEKEMParams bike_params;
case ecdh_sike:
ServerSIKEKEMParams sike_params;
} signed_params;
The parameters are hashed as part of the signing algorithm as The parameters are hashed as part of the signing algorithm as
follows, where H is the hash function used for generating the follows, where H is the hash function used for generating the
signature: signature:
For ECDHE_[KEM]_[SIG]: For ECDHE_[KEM]:
"H( client_random[32] + server_random[32] + ecdh_params + "H( client_random[32] + server_random[32] + ecdh_params +
[KEM]_params)." pq_kem_params)."
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_[KEM]_RSA and hybrid NOTE: This specification only defines hybrid ciphersuites with RSA
key exchange schemes. These cases are defined for TLS 1.2 [RFC5246]. and ECDSA signatures. See [RFC5246] and RFC 8422, respectively, for
SignatureAlgorithm is "ecdsa" for ECDHE_[KEM]_ECDSA. ECDSA details on their use in TLS 1.2.
signatures are generated and verified as described in RFC 8422.
5.2.4. Actions of the sender 5.2.4. Actions of the sender
The server selects elliptic curve domain parameters and an ephemeral The server selects elliptic curve domain parameters and an ephemeral
ECDH public key corresponding to these parameters according to ECDH public key corresponding to these parameters according to
RFC 8422. The server selects BIKE or SIKE parameters and an RFC 8422. The server SHOULD generate a fresh ephemeral ECDH key for
ephemeral public key corresponding to the parameters according to each key exchange so that the hybrid key exchange scheme provides
BIKE or SIKE respectively. It conveys this information to the client forward secrecy. The server selects a PQ KEM parameter set, and uses
in the ServerKeyExchange message using the format defined above. "KeyGen()" for the corresponding parameters of BIKE or SIKE to
generate an ephemeral public key pair. The server MUST generate a
fresh BIKE or SIKE key for each key exchange. A server that receives
a Supported PQ KEM Parameters extension MUST use the client's
enumerated capabilities to guide its selection of an appropriate
cipher suite. The server MUST NOT negotiate the use of a PQ KEM
parameter set unless they can complete the handshake while respecting
the choice of parameters specified by the client (cf.
Section 5.1.6). If the client does not include the PQ KEM Parameters
extension, the server is free to choose any one of the parameters
listed in Section 5.1.6.
If a server is unable to complete the PQ KEM handshake while
restricting itself to the enumerated parameters, it MUST NOT
negotiate the use of the corresponding PQ KEM cipher suite.
Depending on what other cipher suites are proposed by the client and
supported by the server, this may result in a fatal handshake failure
alert due to the lack of common cipher suites.
After selecting a ciphersuite and appropriate parameters, the server
conveys this information to the client in the ServerKeyExchange
message using the format defined above.
5.2.5. Actions of the receiver 5.2.5. Actions of the receiver
The client verifies the signature and retrieves the server's elliptic The client verifies the signature and retrieves the server's elliptic
curve domain parameters and ephemeral ECDH public key and the [KEM] curve domain parameters and ephemeral ECDH public key and the [KEM]
parameters and public key from the ServerKeyExchange message. parameter set and public key from the ServerKeyExchange message.
A possible reason for a fatal handshake failure is that the client's A possible reason for a fatal handshake failure is that the client's
capabilities for handling elliptic curves and point formats are capabilities for handling elliptic curves and point formats are
exceeded (see RFC 8422), the [KEM] parameters are not supported (see exceeded (see RFC 8422), the PQ KEM parameters are not supported (see
Section 5.1), or the signature does not verify. Section 5.1), or the signature does not verify.
5.3. Client Key Exchange 5.3. Client Key Exchange
5.3.1. When this message is sent 5.3.1. When this message is sent
This message is sent in all key exchange algorithms. In the key This message is sent in all key exchange algorithms. In the key
exchanges defined in this document, it contains the client's exchanges defined in this document, it contains the client's
ephemeral ECDH public key and the [KEM] ciphertext value. ephemeral ECDH public key and the [KEM] ciphertext value.
skipping to change at page 14, line 10 skipping to change at page 12, line 43
This message is used to convey ephemeral data relating to the key This message is used to convey ephemeral data relating to the key
exchange belonging to the client (such as its ephemeral ECDH public exchange belonging to the client (such as its ephemeral ECDH public
key and the [KEM] ciphertext value). key and the [KEM] ciphertext value).
5.3.3. Structure of this message 5.3.3. Structure of this message
The TLS ClientKeyExchange message is extended as follows. The TLS ClientKeyExchange message is extended as follows.
struct { struct {
opaque ciphertext <1,..., 2^16 - 1>; opaque ciphertext <1,..., 2^24 - 1>;
} BIKEKEMCiphertext; } PQKEMCiphertext;
where where
o "ciphertext": This is a byte string representation of the BIKE o "ciphertext": This is a byte string representation of the PQ
ciphertext of the KEM construction. Since the underlying calling ciphertext of the KEM construction. Since the underlying calling
convention of the KEM API handles the ciphertext byte string convention of the KEM API handles the ciphertext byte string
directly it is sufficient to pass this as single byte string array directly it is sufficient to pass this as single byte string array
in the protocol. in the protocol.
struct { struct {
opaque ciphertext <1,..., 2^16 - 1>; ClientECDiffieHellmanPublic ecdh_public;
} SIKEKEMCiphertext; PQKEMCiphertext ciphertext;
where
o "ciphertext": This is a byte string representation of the SIKE
ciphertext of the KEM construction. It is the concatenation of a
public_key with a fixed-length masked secret value. Since the
underlying calling convention of the KEM API handles the
ciphertext byte string directly it is sufficient to pass this as
single byte string array in the protocol.
struct {
select (KeyExchangeAlgorithm) {
case ecdh_bike:
ClientECDiffieHellmanPublic ecdh_public;
BIKEKEMCiphertext ciphertext;
case ecdh_sike:
ClientECDiffieHellmanPublic ecdh_public;
SIKEKEMCiphertext ciphertext;
} exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
5.3.4. Actions of the sender 5.3.4. Actions of the sender
The client selects an ephemeral ECDH public key corresponding to the The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to RFC 8422 and parameters it received from the server according to RFC 8422. The
[KEM] ciphertexts according to BIKE or SIKE respectively. It conveys client SHOULD generate a fresh ephemeral ECDH key for each key
this information to the client in the ClientKeyExchange message using exchange so that the hybrid key exchange scheme provides forward
the format defined above. secrecy. Using the "Encaps(pk)" function corresponding to the PQ KEM
and named parameters in ServerKeyExchange message, the client
computes a [KEM] ciphertext. It conveys this information to the
server in the ClientKeyExchange message using the format defined
above.
5.3.5. Actions of the receiver 5.3.5. Actions of the receiver
The server retrieves the client's ephemeral ECDH public key and the The server retrieves the client's ephemeral ECDH public key and the
[KEM] ciphertext from the ClientKeyExchange message and checks that [KEM] ciphertext from the ClientKeyExchange message and checks that
it is on the same elliptic curve as the server's ECDH key, and that it is on the same elliptic curve as the server's ECDHE key, and that
the [KEM] ciphertexts conform to the domain parameters selected by the [KEM] ciphertexts conform to the domain parameters selected by
the server. the server. The server uses the "Decaps(pk)" function corresponding
to the PQ KEM and named parameters in ServerKeyExchange message to
compute the KEM shared secret.
In the case of BIKE there is a decapsulation failure rate no greater In the case of BIKE there is a decapsulation failure rate no greater
than 10^(-7). In the case of a decapsulation failure, an than 10^(-7). In the case of a decapsulation failure, an
implementation MUST abort the handshake. implementation MUST abort the handshake.
5.4. Derivation of the master secret for hybrid key agreement 5.4. Derivation of the master secret for hybrid key agreement
This section defines a new hybrid master secret derivation. It is This section defines a new hybrid master secret derivation. It is
defined under the assumption that we use the concatenated premaster defined under the assumption that we use the concatenated premaster
secret defined in Section 3.1 (Section 3.1). Recall in this case the secret defined in Section 3.1 (Section 3). Recall in this case the
premaster_secret = Z || K, where Z it the ECDHE shared secret, and K premaster_secret = Z || K, where Z it the ECDHE shared secret, and K
is the KEM shared secret. is the KEM shared secret.
We define the master secret as follows: We define the master secret as follows:
master_secret[48] = TLS-PRF(secret, label, seed) master_secret[48] = TLS-PRF(secret, label, seed)
where where
o "secret": the premaster_secret, o "secret": the premaster_secret,
o "label": the string "hybrid master secret", and o "label": the string "hybrid master secret", and
o "seed": the concatenation of "ClientHello.random ||
o "seed": the concatenation of ClientHello.random || ServerHello.random || ClientKeyExchange"
ServerHello.random || ClientKeyExchange
6. Cipher Suites 6. Cipher Suites
The table below defines new hybrid key exchange cipher suites that The table below defines new hybrid key exchange cipher suites that
use the key exchange algorithms specified in Section 2 (Section 2). use the key exchange algorithms specified in Section 2 (Section 2).
+-------------------------------------------------------------------+ +---------------------------------------------------------------+
| Ciphersuite | | Ciphersuite |
+-------------------------------------------------------------------+ +---------------------------------------------------------------+
| CipherSuite TLS_ECDHE_BIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { | | TLS_ECDHE_BIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x01 } |
| 0xFF, 0x01 } | | |
| | | TLS_ECDHE_BIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x02 } |
| CipherSuite TLS_ECDHE_BIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { | | |
| 0xFF, 0x02 } | | TLS_ECDHE_BIKE_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x03 } |
| | | |
| CipherSuite TLS_ECDHE_BIKE_RSA_WITH_AES_128_GCM_SHA256 = { | | TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x04 } |
| 0xFF, 0x03 } | | |
| | | TLS_ECDHE_SIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x05 } |
| CipherSuite TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { | | |
| 0xFF, 0x04 } | | TLS_ECDHE_SIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x06 } |
| | | |
| CipherSuite TLS_ECDHE_SIKE_ECDSA_WITH_AES_128_GCM_SHA256 = { | | TLS_ECDHE_SIKE_RSA_WITH_AES_128_GCM_SHA256 = { 0xFF, 0x07 } |
| 0xFF, 0x05 } | | |
| | | TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x08 } |
| CipherSuite TLS_ECDHE_SIKE_ECDSA_WITH_AES_256_GCM_SHA384 = { | +---------------------------------------------------------------+
| 0xFF, 0x06 } |
| |
| CipherSuite TLS_ECDHE_SIKE_RSA_WITH_AES_128_GCM_SHA256 = { |
| 0xFF, 0x07 } |
| |
| CipherSuite TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { |
| 0xFF, 0x08 } |
+-------------------------------------------------------------------+
Table 2: TLS hybrid key exchange cipher suites Table 2: TLS hybrid key exchange cipher suites
The key exchange method, cipher, and hash algorithm for each of these The key exchange method, signature algorithm, cipher, and hash
cipher suites are easily determined by examining the name. Ciphers algorithm for each of these cipher suites are easily determined by
and hash algorithms are defined in RFC 5288. examining the name. Ciphers and hash algorithms are defined in
RFC 5288.
It is recommended that any implementation of this specification It is recommended that any implementation of this specification
include at least one of include both of the following ciphersuites:
o CipherSuite TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, o TLS_ECDHE_BIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x04 }
0x04 }
o CipherSuite TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, o TLS_ECDHE_SIKE_RSA_WITH_AES_256_GCM_SHA384 = { 0xFF, 0x08 }
0x08 }
using the parameters BIKE1r1-Level1 or SIKEp503r1-KEM. using the parameters BIKE1r1-Level1 and SIKEp503r1-KEM.
7. Security Considerations [DRAFT] 7. Security Considerations [DRAFT]
The security considerations in TLS 1.2 [RFC5246] and RFC 8422 apply The security considerations in TLS 1.2 [RFC5246] and RFC 8422 apply
to this document as well. In addition, as described in RFC 5288 and to this document as well. In addition, as described in RFC 5288 and
RFC 5289, these cipher suites may only be used with TLS 1.2 or RFC 5289, these cipher suites may only be used with TLS 1.2 or
greater. greater.
The description of a KEM is provided in Section 2.1. The security of The description of a KEM is provided in Section 2.1. The security of
the KEM is defined through the indistinguishability K against a the KEM is defined through the indistinguishability against a chosen-
chosen-plaintext (IND-CPA) and against a chosen-ciphertext (IND-CCA) plaintext (IND-CPA) and against a chosen-ciphertext (IND-CCA)
adversary. We are focused here on the IND-CPA security of the KEM. adversary. We are focused here on the IND-CPA security of the KEM.
As a result, implementations MUST NOT use a KEM key more than once,
as reusing keys with IND-CPA KEMs can result in chosen ciphertext
attacks like the GJS attack against BIKE [GJS].
In the IND-CPA experiment of KEMs, an oracle generates keys (sk, pk) In the IND-CPA experiment of KEMs, an oracle generates keys (sk, pk)
with "KeyGen()", computes (c, K) with "Encaps(pk)", and draws with "KeyGen()", computes (c, K) with "Encaps(pk)", and draws
uniformly at random a value R from the key space, and a random bit b. uniformly at random a value R from the key space, and a random bit b.
The adversary is an algorithm A that is given (pk, c, K) if b=1, and The adversary is an algorithm A that is given (pk, c, K) if b=1, and
(pk, c, R) if b=0. Algorithm A outputs a bit b' as a guess for b, (pk, c, R) if b=0. Algorithm A outputs a bit b' as a guess for b,
and wins if b' = b. and wins if b' = b.
All of the ciphersuites described in this document are intended to
provide forward secrecy. The hybrid key exchange mechanism described
in this specification achieves forward secrecy when all ephemeral
keys are single-use. This specification requires single-use PQ KEM
keys, so ephemeral ECDH keys SHOULD also be single-use so that
forward secrecy is achieved.
8. IANA Considerations 8. IANA Considerations
This document describes three new name spaces for use with the TLS This document describes three new name spaces for use with the TLS
protocol: protocol:
9. Acknowledgements 9. Acknowledgements
10. Normative References 10. Normative References
[BIKE] Misoczki, R., Aragon, N., Barreto, P., Bettaieb, S., [BIKE] Misoczki, R., Aragon, N., Barreto, P., Bettaieb, S.,
Bidoux, L., Blazy, O., Deneuville, J., Gaborit, P., Bidoux, L., Blazy, O., Deneuville, J., Gaborit, P.,
Gueron, S., Guneysu, T., Melchor, C., Persichetti, E., Gueron, S., Guneysu, T., Melchor, C., Persichetti, E.,
Sendrier, N., Tillich, J., and G. Zemor, "BIKE: Bit Sendrier, N., Tillich, J., and G. Zemor, "BIKE: Bit
Flipping Key Encapsulation", March 2018, Flipping Key Encapsulation", March 2018,
<http://http://bikesuite.org/files/BIKE.pdf>. <http://http://bikesuite.org/files/BIKE.pdf>.
[GJS] Guo, Q., Johansson, T., and P. Stankovski, "A Key Recovery
Attack on MDPC with CCA Security Using Decoding Failures",
2016, <https://eprint.iacr.org/2016/858.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
DOI 10.17487/RFC5288, August 2008, DOI 10.17487/RFC5288, August 2008,
<https://www.rfc-editor.org/info/rfc5288>. <https://www.rfc-editor.org/info/rfc5288>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
DOI 10.17487/RFC5289, August 2008, DOI 10.17487/RFC5289, August 2008,
<https://www.rfc-editor.org/info/rfc5289>. <https://www.rfc-editor.org/info/rfc5289>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
[SIKE] Jao, D., Azarderakhsh, R., Campagna, M., Costello, C., De [SIKE] Jao, D., Azarderakhsh, R., Campagna, M., Costello, C., De
Feo, L., Hess, B., Jalali, A., Koziel, B., LaMacchia, B., Feo, L., Hess, B., Jalali, A., Koziel, B., LaMacchia, B.,
Longa, P., Naehrig, M., Renes, J., Soukharev, V., and D. Longa, P., Naehrig, M., Renes, J., Soukharev, V., and D.
Urbanik, "Supersingular Isogeny Key Encapsulation", Urbanik, "Supersingular Isogeny Key Encapsulation",
 End of changes. 86 change blocks. 
398 lines changed or deleted 320 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/