| Internet-Draft | TLS Key Share Prediction | September 2023 |
| Benjamin | Expires 28 March 2024 | [Page] |
This document clarifies an ambiguity in the TLS 1.3 key share selection, to avoid a downgrade when server assumptions do not match client behavior. It additionally defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips.¶
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 https://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 28 March 2024.¶
Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Most TLS [RFC8446] parameters are negotiated as follows: The client sends a list of supported options in preference order. Then, the server evaluates this against its own preferences to make a selection. The aim is to arrive at the best common option, without permitting attackers to downgrade to a weaker one. Newer clients and servers often support legacy options for compatibility with older peers. Downgrade-protected parameter selection reduces the security risk of those legacy options when both sides of a connection are newer.¶
Named groups in TLS 1.3 instead use two client lists. The client sends its full preferences in the supported_groups extension, but also generates key shares for a subset in the key_share extension. If the server selects a named group in this subset, the handshake may complete in one round trip. Otherwise, the handshake requires a HelloRetryRequest and two round trips. Unused key shares consume network and computational resources, so clients only predict a subset of supported groups, balancing round-trip reduction against other concerns. This adds another dimension to server group selection.¶
[RFC8446] is ambiguous on the semantics of the key_share subset. Some existing servers assume it reflects client preferences, selecting named groups in key_share above all others. However, the concerns above mean clients may need to predict based on other factors. Where these interpretations conflict, the selection may be downgraded, potentially even under attacker influence.¶
This document resolves the ambiguity in three ways:¶
It is expected that all post-quantum key encapsulation methods (KEMs) will fall in the last category. Post-quantum KEMs have large keys and ciphertexts, so bandwidth concerns are particularly pronounced.¶
This document additionally defines a method for servers to declare their named group preferences in DNS, using SVCB or HTTPS resource records [I-D.ietf-dnsop-svcb-https]. This allows the client to predict key shares more accurately.¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Some existing TLS 1.3 servers implement the following named group selection algorithm:¶
key_share. If found, select it and send ServerHello.¶
supported_groups. If found, select it and send HelloRetryRequest.¶
handshake_failure alert.¶
While this algorithm avoids HelloRetryRequest whenever possible, it implicitly assumes the client prefers the values sent in key_share, and that the server has no preferences between any groups. If these assumptions do not hold, the server's selection may be downgraded.¶
The following sections describe example downgrade scenarios with this algorithm. postquantum1 and postquantum2 refer to future post-quantum named groups, which both client and server prefer over x25519.¶
Consider a client which implements, in preference order, postquantum2, postquantum1, and x25519. Sending keys for both postquantum2 and postquantum1 is expensive, so the client only predicts one of them. postquantum2 is preferred (e.g. more efficient or more commonly deployed), and older x25519-only servers still exist, so the client predicts postquantum2, x25519 in key_share.¶
If the server predates postquantum2 and only implements postquantum1 and x25519, it will select x25519, although postquantum1 is available in supported_groups.¶
The client may predict key shares based on prior knowledge about the server, such as a DNS hint (see Section 4). For example, during a transition from postquantum1 to postquantum2, both options will be available in the ecosystem. The client may use a DNS hint to avoid needing HelloRetryRequest with both existing and upgraded servers.¶
If the client's prior knowledge is outdated or under attacker influence, this can lead to a downgrade. Suppose the server implements postquantum1 and x25519, but the client believed it only implemented x25519. The client may then predict x25519 in key_share, leading the server to select x25519 over the preferred postquantum1.¶
Software bugs in existing TLS servers may prevent them from processing larger ClientHellos. During an early rollout of post-quantum KEMs, a client may prefer postquantum1, but sometimes only predict x25519 to reduce compatibility risk, expecting that newer servers can still select it with HelloRetryRequest.¶
However, a server implementing the above algorithm would instead select x25519 over the preferred postquantum1.¶
TLS 1.3 servers implementing this document MUST NOT assume the client's key_share extension reflects client preferences. Instead, servers SHOULD select the best common named group based on supported_groups, without reference to key_share. The server then looks for the selected named group in key_share to decide whether to send HelloRetryRequest or ServerHello.¶
If choosing between two named groups which the server equally prefers, and for which the server is willing to ignore the client's supported_groups preference order, the server MAY use presence in the client's key_share extension to select one which will avoid HelloRetryRequest. However, attackers may then influence which of the two is chosen.¶
Note the algorithm in Section 3.1 is permitted if the above applies to all of a server's supported groups. However, this is unlikely to apply if the server implements a combination of post-quantum and legacy named groups, or if the server software's configuration specifies a preference order.¶
Although Section 3.2 defines new rules for TLS 1.3 servers, TLS 1.3 has already been deployed. Clients that assume a server implements the new rules may introduce a downgrade attack on a pre-existing server. To avoid this, this document uses named group codepoints to distinguish the old and new behavior.¶
A named group is considered prediction-safe if the value in the "Prediction-Safe" column of the registry (see Section 6) is "Y". Otherwise, it is considered prediction-unsafe. Any TLS server which implements a prediction-safe named group MUST follow the guidelines in Section 3.2. To be a prediction-safe named group, the defining specification MUST cite this document and include such a requirement. For example:¶
TLS servers which support this named group MUST select parameters as described in Section 3.2 of [this-RFC].¶
When sending the initial ClientHello, clients SHOULD ensure the prediction-unsafe groups in the key_share extension are consistent with its preferences. This is determined by the following procedure:¶
key_share_pred_unsafe be the list of prediction-unsafe named groups in the key_share extension¶
supported_groups_pred_unsafe be the list of prediction-unsafe named groups in the supported_groups extension¶
key_share extension is consistent if and only if key_share_pred_unsafe is a prefix of supported_groups_pred_unsafe¶
This procedure ignores all prediction-safe named groups. Clients MAY freely vary whether a prediction-safe named group is included, including using untrusted signals.¶
For example, suppose safe1 and safe2 are prediction-safe, while unsafe1 and unsafe2 are prediction-unsafe. If the client's supported_groups extension contains, in order, safe1, unsafe1, safe2, unsafe2, the following key_share predictions would meet this criteria:¶
The following would not:¶
If the client has trusted, prior knowledge that the server implements a selection algorithm consistent with Section 3.2, it MAY disregard the above and freely vary both prediction-safe and prediction-unsafe groups.¶
This section defines the tls-supported-groups SvcParamKey [I-D.ietf-dnsop-svcb-https], which specifies the endpoint's TLS supported group preferences, as a sequence of TLS NamedGroup codepoints in order of decreasing preference.¶
The presentation value of the SvcParamValue is a comma-separated list (Appendix A.1 of [I-D.ietf-dnsop-svcb-https]) of decimal integers between 0 and 65536 in ASCII. Any other value is a syntax error. To enable simpler parsing, this SvcParam MUST NOT contain escape sequences.¶
The wire format of the SvcParamValue is a sequence of 2-octet numeric values in network byte order. An empty list of values is invalid.¶
Services SHOULD include supported TLS named groups, in order of decreasing preference in the tls-supported-groups parameter of their HTTPS or SVCB endpoints. As TLS preferences are updated, services SHOULD update the DNS record to match. Services MAY include GREASE values [RFC8701] in this list.¶
A service MUST NOT configure this service parameter if any of the corresponding TLS servers do not implement the TLS server guidance in Section 3.2.¶
When connecting to a service endpoint whose HTTPS or SVCB record contains the tls-supported-groups parameter, the client evaluates the server preferences against its own and predicts named groups to send in the key_share extension. In evaluating the server preferences, the client MUST ignore any codepoints that it does not support or recognize.¶
If one of the following hold, the client MAY use the result to predict key shares in the initial ClientHello:¶
Otherwise, the client SHOULD ignore the parameter and compute key_share via its usual logic. Note a secure connection to the DNS resolver, such as DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], is not sufficient to authenticate the record by the origin server.¶
Although this service parameter is intended to reduce key share mispredictions, mispredictions may still occur. For example, HelloRetryRequest may be required in the following cases:¶
Clients and servers MUST correctly handle mispredictions by responding to or sending HelloRetryRequest, respectively.¶
This document updates TLS server behavior and introduces a notion of prediction-safe named groups to avoid the downgrades in Section 3.1, for both new and existing TLS 1.3 implementations:¶
key_share prediction criteria, even under attacker influence.¶
If a TLS server implements a prediction-safe named group but does not follow the guidelines in Section 3.2, downgrades are possible. Thus Section 3.3 requires all prediction-safe named groups to include text referencing this document.¶
This document updates the TLS Supported Groups registry [RFC8422] to add a "Prediction-Safe" column immediately following the "Recommended" column. The "Prediction-Safe" column is set to a value of "N" for all existing allocations except for X25519Kyber768Draft00 and SecP256r1Kyber768Draft00. Those two values should be set to "Y".¶
[[TODO: As of writing, neither of the Kyber768 hybrids above include the necessary text. But, as Kyber is a large post-quantum KEM, it's desirable for them to be prediction-safe. If this document is adopted, the respective Kyber drafts can be updated to incorporate the necessary sentence.]]¶
This document additional adds the following note to the registry:¶
Note: Section 3.3 of [this-RFC] defines the procedure for a group to be considered prediction-safe and thus set the corresponding column to a value of "Y". All new allocations to this registry are expected to be prediction-safe, unless some interoperability consideration prevents it. For example, if the new allocation is documenting a pre-existing deployment with the older server behavior, it may be allocated with a value of "N".¶
This document updates the Service Parameter Keys registry [I-D.ietf-dnsop-svcb-https] with the following entry:¶
| Number | Name | Meaning | Format Reference | Change Controller |
|---|---|---|---|---|
| TBD | tls-supported-groups | Supported groups in TLS | (this document) Section 4.1 | IETF |
The author would like to thank David Adrian, Bob Beck, Sophie Schmieg, and Bas Westerbaan for discussions and review on initial iterations of this document.¶