| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
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 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.
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.
This document extends the ExtensionType enum as follows:
enum {
...,
additional_key_share(XX),
(65535)
} ExtensionType;
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;
The “extension_data” field of the “additional_key_share” extension contains an “AdditionalKeyShare” value.
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;
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 “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.
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.
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].
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.)
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.
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:
When an additional secret is derived through “additional_key_share” the order is:
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
[[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 “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:
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].
IANA [SHALL add/has added] a new entry to the TLS extensions ExtensionType values registry for “additional_key_share”.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [NISTPQFAQ] | NIST, "Post-Quantum Crypto Standardization FAQ", April 2017. |
| [TLS13draft19] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", March 2017. |