Network Working Group J. Schanck
Internet-Draft University of Waterloo
Intended status: Experimental D. Stebila
Expires: October 19, 2017 McMaster University
April 17, 2017
A Transport Layer Security (TLS) Extension For Establishing An
Additional Shared Secret
draft-schanck-tls-additional-keyshare-00
Abstract
This document defines a Transport Layer Security (TLS) extension that
allows parties to establish an additional shared secret using a
second key exchange algorithm and incorporates this shared secret
into the TLS key schedule.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Schanck & Stebila Expires October 19, 2017 [Page 1]
Internet-Draft Additional Key Share TLS Extension April 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. Additional Key Share Extension . . . . . . . . . . . . . . . 4
2.1. ExtensionType . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Existing data structures . . . . . . . . . . . . . . . . 4
2.3. AdditionalKeyShare extension . . . . . . . . . . . . . . 4
2.3.1. Requirements for use in ClientHello . . . . . . . . . 5
2.3.2. Requirements for use in ServerHello . . . . . . . . . 6
2.3.3. Requirements for use in HelloRetryRequest . . . . . . 6
2.4. Backward Compatibility . . . . . . . . . . . . . . . . . 6
2.4.1. Negotiating with a server that does not support the
additional_key_share extension . . . . . . . . . . . 6
2.4.2. Negotiating with a client that does not support the
additional_key_share extension . . . . . . . . . . . 6
3. Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Pre-shared key modes and session resumption . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The key schedule of TLS 1.3 [TLS13draft19] is capable of extracting
session key material from multiple shared secrets. A notable use of
this feature is in forward secret pre-shared key (PSK) modes wherein
a PSK is combined with an ephemeral shared secret established through
a Diffie-Hellman exchange. While the key schedule can process
arbitrary lists of shared secrets, it is currently only possible to
incorporate a pre-shared key and a shared secret established through
the "key_share" extension.
This document defines a TLS ClientHello, HelloRetryRequest, and
ServerHello extension of type "additional_key_share" that allows
parties to establish an additional shared secret.
This document does not define any named groups or key exchange modes.
Schanck & Stebila Expires October 19, 2017 [Page 2]
Internet-Draft Additional Key Share TLS Extension April 2017
1.1. Use cases
One use case is to provide pre- to post-quantum transitional security
while hedging against potential weaknesses of post-quantum
algorithms. A post-quantum cryptographic algorithm is one that is
believed to be resistant to attacks by quantum computers; algorithms
based on factoring and discrete log are said to be pre-quantum.
Authenticated and confidential channel establishment protocols are
said to be secure in a transitional setting if they provide pre-
quantum authentication and post-quantum confidentiality. Such
protocols provide forward secrecy so long as adversaries do not have
quantum computers at the time of session establishment.
An additional key share can be used to combine a high-confidence pre-
quantum confidentiality mechanism with a more experimental post-
quantum confidentiality mechanism without any added risk.
One could argue that if post-quantum algorithms are available then
they should be used in place of pre-quantum algorithms. However
there are several reasons why a user might not want to rely solely on
a post-quantum algorithm today. First, confidence in cryptographic
assumptions relies in part on the duration and intensity of their
study. Most post-quantum assumptions have received less scrutiny
than DH or ECDH, and cryptanalysis may progress rapidly as more
attention is drawn to these assumptions. Second, the cryptographic
community has less experience writing secure implementations of post-
quantum algorithms, and one may be concerned that there are yet-to-
be-discovered implementation pitfalls and side-channel attacks that
could compromise confidentiality. Finally there may be users who are
required to use certain pre-quantum algorithms, but who nevertheless
desire forward secrecy against post-quantum adversaries. For
example, NIST has made it clear that hybrid modes are not
incompatible with FIPS 140 validation [NISTPQFAQ].
The simultaneous use of pre-quantum and post-quantum algorithms
provides users with the potential of long-term, quantum-resistant
confidentiality without any added risk.
1.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
In [TLS13draft19], all asymmetric key exchange modes are either
(finite field) Diffie-Hellman or elliptic curve Diffie-Hellman, and
the term "named group" is used to identify which group. Some key
Schanck & Stebila Expires October 19, 2017 [Page 3]
Internet-Draft Additional Key Share TLS Extension April 2017
exchange mechanisms, especially post-quantum mechanisms, are not
parameterized by a group. However, we continue to use the term
"named group" to identify a key exchange mechanism more broadly.
2. Additional Key Share Extension
The "additional_key_share" extension replicates the functionality of
the "key_share" extension defined in [TLS13draft19], although there
are some semantic differences between the two extensions.
2.1. ExtensionType
This document extends the ExtensionType enum as follows:
enum {
...,
additional_key_share(XX),
(65535)
} ExtensionType;
2.2. Existing data structures
The definition of the AdditionalKeyShare extension requires the
KeyShareEntry and NamedGroup structs defined in [TLS13draft19].
NamedGroup is a 2-octet enum. For convenience of the reader, we
reproduce the definition of KeyShareEntry from [TLS13draft19] below:
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
2.3. AdditionalKeyShare extension
The "extension_data" field of the "additional_key_share" extension
contains an "AdditionalKeyShare" value.
Schanck & Stebila Expires October 19, 2017 [Page 4]
Internet-Draft Additional Key Share TLS Extension April 2017
struct {
select (Handshake.msg_type) {
case client_hello:
KeyShareEntry additional_client_shares<0..2^16-1>;
case hello_retry_request:
NamedGroup additional_selected_group;
case server_hello:
KeyShareEntry additional_server_share;
};
} AdditionalKeyShare;
additional_client_shares A list of offered KeyShareEntry values in
descending order of client preference.
additional_selected_group A mutually supported key exchange
algorithm that the server is willing to negotiate if the client
sends an "additional_key_share" extension in a new ClientHello.
additional_server_share A single KeyShareEntry value that is in the
same NamedGroup as one of the client's shares.
2.3.1. Requirements for use in ClientHello
The client MUST NOT send the "additional_key_share" extension without
sending the "key_share" extension. The client MAY send an empty
"additional_client_shares" vector when requesting a
HelloRetryRequest, but SHOULD NOT do so otherwise.
The client MUST NOT offer a KeyShareEntry value for a NamedGroup that
is not listed in the "supported_groups" extension.
The client MUST NOT offer multiple KeyShareEntry values in the
"additional_client_shares" vector for the same NamedGroup. This is
because the "additional_server_share" value of the server's
"additional_key_share" extension must uniquely identify the client
share to which it corresponds.
The client MAY offer a KeyShareEntry value in
"additional_client_shares" for a NamedGroup that they offered in
their "key_share" extension, as this causes no ambiguity.
Each value in the client's "additional_client_shares" vector MUST be
generated independently. The independence requirement extends to the
KeyShareEntry values offered in the "key_share" extension. In
particular, the client MUST NOT offer KeyShareEntry values in
Schanck & Stebila Expires October 19, 2017 [Page 5]
Internet-Draft Additional Key Share TLS Extension April 2017
"additional_key_share" that duplicate the contents of KeyShareEntry
values offered in "key_share".
The server MAY check for violations of these rules and MAY abort the
connection with a fatal "illegal_parameter" alert if a rule is
violated.
2.3.2. Requirements for use in ServerHello
The server MUST NOT send a KeyShareEntry for any NamedGroup not
indicated in the "supported_groups" extension. The server MUST NOT
send a KeyShareEntry for a NamedGroup that does not match one of the
client's offers.
2.3.3. Requirements for use in HelloRetryRequest
The server MAY send HelloRetryRequest based on the contents of the
client's "additional_client_shares" vector. The client processes
this message as in Section 4.2.5 of [TLS13draft19].
2.4. Backward Compatibility
2.4.1. Negotiating with a server that does not support the
additional_key_share extension
If a server does not provide an "additional_key_share" extension in
its ServerHello, the client MAY abort the handshake with a
"missing_extension" alert, or the client MAY finish the handshake
based on the server's "key_share" extension. (The latter allows a
client to negotiate a connection with a server who does not recognize
this extension without retrying the handshake.)
2.4.2. Negotiating with a client that does not support the
additional_key_share extension
If a client does not provide an "additional_key_share" extension in
its ClientHello, the server MAY abort the handshake with a
"missing_extension" alert, or the server MAY finish the handshake
based on the client's "key_share" extension.
If the server chooses to finish the handshake based on the client's
"key_share" extension, this allows a server that supports both pre-
quantum and post-quantum key exchange to negotiate a connection with
a client that does not recognize this extension and only supports
pre-quantum key exchange.
Schanck & Stebila Expires October 19, 2017 [Page 6]
Internet-Draft Additional Key Share TLS Extension April 2017
3. Key Schedule
The presence of the "additional_key_share" extension alters the
derivation of the master secret. The key schedule employed by TLS
1.3 handles a list of input secrets by iteratively invoking HKDF-
Extract. When the "additional_key_share" extension is not present,
secrets are processed in the following order:
o PSK
o (EC)DHE shared secret.
When an additional secret is derived through "additional_key_share"
the order is:
o PSK
o (EC)DHE shared secret
o Additional secret.
Schanck & Stebila Expires October 19, 2017 [Page 7]
Internet-Draft Additional Key Share TLS Extension April 2017
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+--> Derive-Secret(...) = binder_key
+--> Derive-Secret(...) = client_early_traffic_secret
+--> Derive-Secret(...) = early_exporter_secret
|
v
Derive-Secret(., "derived secret", "")
|
v
(EC)DHE -> HKDF-Extract
|
v
Derive-Secret(., "derived secret", "")
|
|
Additional v
Secret -> HKDF-Extract = Handshake Secret
|
+--> Derive-Secret(...) = client_handshake_traffic_secret
+--> Derive-Secret(...) = server_handshake_traffic_secret
|
v
Derive-Secret(., "derived secret", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+--> Derive-Secret(...) = client_traffic_secret_0
+--> Derive-Secret(...) = server_traffic_secret_0
+--> Derive-Secret(...) = exporter_secret
+--> Derive-Secret(...) = resumption_master_secret
4. Pre-shared key modes and session resumption
[[FOR DISCUSSION]]
TLS 1.3 allows the client to restrict the use of PSKs that they
provide in ClientHello through the "psk_key_exchange_modes"
extension. The client may, for instance, request that the PSK only
be used in a PSK+(EC)DHE mode, so as to ensure that the resumed
session has forward secrecy.
If the client sends "additional_key_share" in an initial ClientHello,
it is reasonable to expect that they will want to use
Schanck & Stebila Expires October 19, 2017 [Page 8]
Internet-Draft Additional Key Share TLS Extension April 2017
"additional_key_share" in PSK-resumption. It is possible to
accomodate such a client by defining a new PskKeyExchangeMode,
however there is a caveat in doing so that we feel it is worth
pointing out.
Suppose that a PSK has been established through some combination of
pre-quantum and post-quantum mechanisms, as in our proposed use case.
This PSK is treated as long-term key material during resumption, so a
"psk_dhe_ke" mode would not be sufficient to preserve the security
properties of the initial handshake, namely forward secrecy against
post-quantum adversaries. To avoid this, a post-quantum mechanisms
must be used in the resumption handshake.
It is not sufficient to require the use of "additional_key_share"
during resumption, as this could be used to combine two pre-quantum
mechanisms.
Possible remedies:
o Add a new PskKeyExchangeMode that enforces the use of the same
NamedGroups that were used to establish the initial secret. enum
{ ..., psk_same_groups_ke(XX), (255) } PskKeyExchangeMode;
o Add a new PskKeyExchangeMode for "transitional" security enum {
..., psk_transitional_ke(XX), (255) } PskKeyExchangeMode;
5. Security Considerations
This document does not change the intended security properties of
TLS. In particular, it retains the goals of "establishing the same
session key" and "secrecy of the session key" as described in
Appendix E.1 of [TLS13draft19].
6. IANA Considerations
IANA [SHALL add/has added] a new entry to the TLS extensions
ExtensionType values registry for "additional_key_share".
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Schanck & Stebila Expires October 19, 2017 [Page 9]
Internet-Draft Additional Key Share TLS Extension April 2017
7.2. Informative References
[NISTPQFAQ]
NIST, "Post-Quantum Crypto Standardization FAQ", April
2017, <http://csrc.nist.gov/groups/ST/post-quantum-crypto/
faq.html#Q1>.
[TLS13draft19]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", March 2017, <https://tools.ietf.org/html/
draft-ietf-tls-tls13-19>.
Authors' Addresses
John M. Schanck
University of Waterloo
200 University Avenue West
Waterloo, ON N2L 3G1
Canada
Email: jschanck@uwaterloo.ca
Douglas Stebila
McMaster University
1280 Main Street West
Hamilton, ON L8S 4L8
Canada
Email: stebilad@mcmaster.ca
Schanck & Stebila Expires October 19, 2017 [Page 10]