| TLS Working Group | T. Putman |
| Internet-Draft | Dyson Technology |
| Intended status: Informational | January 31, 2018 |
| Expires: August 4, 2018 |
Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs for (Datagram) Transport Layer Security ((D)TLS) Protocol version 1.3
draft-putman-tls13-preshared-dh-00
This document defines an authenticated key agreement method for the Transport Layer Security (TLS) protocol version 1.3. The authentication method requires that the server (and optionally client) is pre-provisioned with a unique long-term static asymmetric Finite Field Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) keypair; the peer must be able to obtain the public key of the endpoint via an out-of-band mechanism (e.g. pre-provisioning). The handshake provides ephemeral (EC)DH keys, and a common key schedule is agreed using Double- or Triple-(EC)DH. Confirmation of knowledge of the key schedule provides server (and optionally client) authentication.
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 August 4, 2018.
Copyright (c) 2018 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 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.
Often, constrained devices use pre-shared keys (PSK) for authentication and key agreement. A drawback of this is that if the server database of pre-shared keys is compromised, then this means that not only can the server be impersonated to the clients, but also the symmetric nature of the keys means that the clients can be impersonated to the server.
In consequence, a large-scale database compromise can result in large-scale client impersonation. This is very hard to recover from because any remote update to the clients risks providing the updated information to an adversary.
This document describes the use of asymmetric pre-shared keys to address this data-loss scenario. It assumes that an out-of-band method of pre-configuring the asymmetric keys into the endpoints exists, and this method is outside the scope of this document. The primary intended usage is for constrained devices, but the method may be used in other circumstances where the peer's public key may be securely obtained out-of-band (e.g. via DNSSEC).
Another advantage of asymmetric pre-shared keys over symmetric pre-shared keys is that it is easier to protect a single server private key using hardware-based security than it is to protect a database of shared symmetric keys.
In [I-D.ietf-tls-tls13], all key exchange methods except those based on PSK require perfect forward secrecy (PFS), which in turn requires (at present) either Diffie-Hellman or Elliptic Curve Diffie-Hellman. The number of constrained devices which can be accommodated is increased if the key agreement also provides authentication, so that no other public key algorithms are required.
Even if the device contains code for other public key algorithms (e.g. EdDSA for code update signature checking), these may be coded to use a slow variant of the algorithm to conserve code and data space. In addition, hardware support for ECDH is likely to be introduced in many constrained devices, as it is required for wireless communications (e.g. Bluetooth Mesh), whereas signing algorithms are not.
Double-(EC)DH [Blake-Wilson] could be used for authenticated key agreement, but this would not provide PFS. PFS can be provided by using Triple-(EC)DH [Kudla] with no change to the protocol messages; it only adds to the cost of computing the keying material by adding one additional (EC)DH computation.
In order to break forward secrecy in Double-(EC)DH, the attacker must obtain the static (EC)DH private keys of both client and server. This is likely to be a difficult feat, so both Double- and Triple-(EC)DH are specified in this document as this increases the number of constrained devices which are able to use this method.
Perfect Forward Secrecy (PFS) is a strongly recommended feature in security protocol design and is mandatory to implement in both HTTP/2 and (for non-PSK deployments) CoAP. Therefore, Triple-(EC)DH SHOULD be used for those deployments where the client devices are able to support the additional computation.
The authentication methods defined in this document are primarily intended for a narrow set of applications, where there is a well-established relationship between clients and servers and where, in addition, there are severe constraints on the client capabilities. Even in such deployments, other alternatives may be more appropriate.
If the loss of server data is not of concern, then the use of symmetric pre-shared keys may be more appealing. If, on the other hand, the main goal is to avoid Public-Key Infrastructures (PKIs), then the use of raw public keys may be preferrable.
A secondary use of this authentication method is to support 0-RTT traffic in a situation where no (current) session tickets exist. The server in this situation will typically not have knowledge of the client, so a method which supports only server authentication is also supported.
The 2/3(EC)DH authenticated key agreement modes offer advantages over other schemes, but there are limitations as well. A summary of advantages and disadvantages are given in the following table:
| Alternative Authentication Mode | 2/3(EC)DH Advantage | 2/3(EC)DH Disadvantage |
|---|---|---|
| External PSK | Server breach does not permit client impersonation; hardware protection for server key possible; client identity is confidential | Public-key computations needed |
| Raw Public Keys | Supports 0-RTT messages; only one public-key algorithm used; shorter messages | Separate server keypair needed if it also supports PKI |
| Certificate Authentication | Supports 0-RTT messages; only one public-key algorithm used; no certificate parsing; much shorter messages | Out-of-band public key distribution needed (e.g. pre-provisioning, DNSSEC) |
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.
This section defines the key exchange mechanisms which are used for 2(EC)DH and 3(EC)DH. The message exchange is identical to that used for PSK with (EC)DHE key establishment, and is reproduced below in Figure 1. Although the message exchange is identical, the pre-shared keys have extra semantics applied and the key schedule is different.
Client Server
Key ^ ClientHello
Exch | + key_share
| + psk_key_exchange_modes
v + pre_shared_key -------->
ServerHello ^ Key
+ key_share | Exch
+ pre_shared_key v
{EncryptedExtensions}
{Finished} : Auth
<-------- [Application Data*]
Auth : {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
* Indicates optional or situation-dependent
messages/extensions that are not always sent.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N
Figure 1: Message flow for 2/3(EC)DH TLS Handshake
Details of the PSK identity format which is used with 2/3{EC}DH is given in section Section 3. To understand the key exchange explained here, it only necessary to know that the PSK identity is the concatenation of a server PSK identity with an optional encrypted client PSK identity. The server PSK identity is uniquely associated with an (EC)DH private/public keypair, and the client PSK identity is present if and only if a key share on the named curve corresponding to the server PSK identity is present in the ClientHello message.
The client indicates its willingness to use 2/3(EC)DH authenticated key exchange by including at least one compatible identity in its "pre_shared_key" extension. Support for 2(EC)DH versus 3(EC)DH is indicated by including the values psk_ke or psk_dhe_ke respectively in the "psk_key_exchange_modes" extension; as with other pre-shared key methods, psk_ke does not support PFS, whereas psk_dhe_ke does. The client MUST NOT include more than one identity which is associated with the same server PSK identity: doing so would compromise the security of the encrypted client PSK identity. The client MUST also include in the "supported_groups" extension all (EC)DH groups which are needed to establish a key exchange for any of the provided PSK identities: 2/3(EC)DH key exchange requires that all static and ephemeral (EC)DH keys are in the same named group.
If the TLS server accepts the use of 2(EC)DH or 3(EC)DH, then it selects a PSK identity which corresponds to the chosen key exchange mode from the list of offered identities in the "pre_shared_key" extension of the ClientHello message. As with other PSK modes, the server MUST ensure that the selected PSK and cipher suite are compatible, and it may do this by selecting the cipher suite first then excluding all incompatible PSKs.
Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 of [I-D.ietf-tls-tls13]). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK.
The server MUST support 3(EC)DH on each of its server PSK identities, and may support 2(EC)DH on any subset of identities (including all or none). The client MAY be willing to establish key exchange either with or without PFS, indicated by including both the psk_ke and psk_dhe_ke values in the "psk_key_exchange_mode" extension. If, in this situation, the server chooses to use a 2/3(EC)DH identity, then it SHALL select the 3(EC)DH key exchange method. The client MUST support this behavior by constructing the corresponding binder using the 3(EC)DH binding key; if it does not, then the handshake will fail.
The selected PSK identity identifies a server static (EC)DH private/public keypair and implicitly also a named group. If the ClientHello message does not contain a key share for this group, then the server SHALL request the key share by sending a HelloRetryRequest which indicates the selected PSK identity in the "pre_shared_key" extension. If the ClientHello message does contain a key share for this group but the selected identity does not contain an encrypted client identity, then the server SHALL abort the handshake with an "illegal_parameter" alert.
A client SHOULD remember which server PSK identity a server preferred in previous sessions and SHOULD include the corresponding key share in the first ClientHello message when establishing future sessions. This will reduce the number of HelloRetryRequest messages from the server and will speed up session establishment.
If the ClientHello is sent in response to a HelloRetryRequest, then it MUST only contain the PSK identity selected by the server. It MUST also contain in the "key_share" extension an ephemeral (EC)DH key which is on the named curve associated with the server PSK identity. Consequently, the PSK identity will contain both the server PSK identity and the encrypted client PSK identity.
If 2/3(EC)DH PSK key exchange mode is selected, then the server decrypts the client identity and, if it is not an anonymous client, obtains the corresponding client static public (EC)DH key. If it accepts anonymous clients or if it accepts the identified client, then the server responds with a ServerHello message; this message MUST include a "pre_shared_key" extension which indicates the selected PSK identity and an ephemeral key share in the same named group as the selected static (EC)DH key. It SHALL NOT send Certificate or CertificateRequest messages.
Both peers MUST use the selected ephemeral and static (EC)DH keys to derive the key schedule using either 2(EC)DH or 3(EC)DH, depending on the selected key exchange mode, as specified in section Section 5.1.
If the 2/3(EC)DH PSK key exchange mode is selected and the decrypted client identity is not recognised, or if it indicates an anonymous client and the server is configured to reject anonymous clients, then the server SHALL select a valid unused public key to use for the purposes of computing the key binding, and only reject the handshake when the binding check fails. This is needed to prevent an oracle attack on client identity confidentiality where the attacker replays a ClientHello but modifies the encrypted client identity in a controlled way.
The format of a PSK identity defined in [I-D.ietf-tls-tls13] is opaque<1..2^16-1>, but additional structure is needed to support confidentiality of the client PSK identity; this structure remains opaque to the protocol, but must be agreed between the end-points using an out-of-band mechanism.
An identity which is associated with 2/3(EC)DH key exchange SHALL be the concatenation of a server PSK identity with an optional encrypted client PSK identity.
A server which supports 2(EC)DH and/or 3(EC)DH MUST have one or more identities associated with it for the purposes of (EC)DH PSK key exchange. Each identity is associated with a single static (EC)DH private/public keypair and Hash algorithm; these identities are provided to the clients via an out-of-band mechanism (e.g. pre-provisioning) which is outside the scope of this specification.
To simplify processing, the server PSK identities SHOULD all be the same size; if the server has a single PSK identity, then it MAY be NULL (zero length), but this is NOT RECOMMENDED as this complicates the addition of new identities. Also, the server SHOULD ensure that PSK identities which are established by the session ticket mechanism are always distinguishable from 2/3(EC)DH PSK identities; for example, if the session ticket is constructed as described in section 4 of [RFC5077], then the opaque "key_name" should be chosen so that it does not collide with any of the server PSK identities.
The encrypted client PSK identity MUST be present if the corresponding key share is present in the "key_share" extension, and MUST NOT be present otherwise. If the server has a NULL identity, then the minimum length of the PSK identity requires that the client PSK identity must be present; this in turn means that the corresponding key share must be present in the "key_share" extension.
A single server MAY support multiple static (EC)DH keys across one or more named curves by having multiple server PSK identities. This allows rotation of static keys on a single curve, or migration from a weaker named curve or hash algorithm to a stronger one. The policies required to rotate keys or change curves/hash algorithms are outside the scope of this specification, but if such a change is instigated then the overlap period during which both keys are supported should be sufficiently long to ensure that all clients have been updated.
As suggested earlier, the server SHOULD ensure that the different PSK identities that it is prepared to process are readily distinguishable. If it mis-classes an identity then the binding check will fail and the session will not be established. The contents of the server PSK identity field are opaque, so this may be done by keeping all PSK identities of this server the same length or by preceding the server PSK identity with a length field. Each server PSK identity is associated with a single (EC)DH private/public keypair and hash algorithm, so the identity may be formed from a root name with the corresponding curve name (and optionally hash algorithm) appended.
When present, the client PSK identity is encrypted. The encryption key is derived as described in section Section 5.1 and depends on the client key share (among other things). For this reason, the client PSK identity cannot be present if the corresponding key share is not present and this forces the server to send a HelloRetryRequest if this server PSK identity is selected.
Any string of all zero bytes of any length is reserved for an anonymous client and MUST NOT be used for an actual client PSK identity. It is RECOMMENDED that all client PSK identities are the same length, in which case this length SHOULD be publicised so that an anonymous client can use an identity of the same length. Alternatively, if different lengths are supported for client PSK identities, then the client and server SHOULD support padding of the identity with leading zero bytes to prevent client identification by correlating the length of the encrypted PSK identity string in different handshake sequences.
It is expected that different types of client and server identities are useful for different applications running over TLS. This document does not therefore mandate the use of any particular type of identity (such as IPv4 address or Fully Qualified Domain Name (FQDN)).
However, the TLS client and server clearly have to agree on the identities and keys to be used. To improve interoperability, this document places requirements on how the identity is encoded in the protocol, and what kinds of identities and keys implementations have to be supported.
The requirements for implementations are divided into two categories, requirements for TLS implementations and management interfaces. In this context, "TLS implementation" refers to a TLS library or module that is intended to be used for several different purposes, while "management interface" would typically be implemented by a particular application that uses TLS.
This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives. For instance, if the identity is a domain name, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that before looking up the key, the server processes the client PSK identity with a PRECIS framework (see [RFC7564]) appropriate for the identity in question (such as [RFC5891] for components of domain names or [RFC8265] for usernames).
The server and client PSK identities MUST be first converted to a character string, and then encoded to octets using UTF-8; the server PSK identity MAY be preceded by a single-octet length field and the client PSK identity MAY be preceded by a variable number of zero octets. For instance,
This encoding is clearly not optimal for many types of identities. It was chosen to avoid identity-type-specific parsing and encoding code in implementations where the identity is configured by a person using some kind of management interface. Requiring such identity-type-specific code would also increase the chances for interoperability problems resulting from different implementations supporting different identity types.
TLS implementations supporting 2/3(EC)DH key agreement MUST support arbitrary client PSK Identities up to 128 octets in length, and MUST provide a server PSK identity which uses a static ECDH key on the named curve P-256. Supporting longer identities and other ECDH curves is RECOMMENDED.
The server MUST provide information out-of-band regarding what format(s) of client PSK identity it supports for each server PSK identity, together with the server (EC)DH public key and hash function. This information includes the supported length(s) of the client PSK identity, the padding method (if any) and whether it accepts anonymous clients or not.
In the absence of an application profile specification specifying otherwise, a management interface for entering the pre-shared private/public keys, and/or PSK Identity MUST support the following:
A number of computations in this protocol require substantial resources from a constrained client. Some of these may be precomputed, which reduces the time taken during the actual session establishment, and so may improve the success rate of the handshake.
If the client only communicates with a small number of servers, then the static-static shared secret (C_s/S_s) may be computed once only and stored for all future communications, or may be computed offline and preprovisioned. If this is done, then the secret SHOULD be protected with the same level of security as is used to protect the client private key; exposure of this key would allow the impersonation of 0-RTT traffic. If the client does not store this shared secret, then it may compute it before starting the handshake.
Prior to starting each handshake, the client should accumulate sufficient entropy to generate all the session-specific secrets. These include the client ephemeral (EC)DH keypair and the ClientHello.random value. Accumulating entropy in a constrained device may take a great deal of time; if so, then this should be done as a background task.
Prior to starting each handshake, the client will usually generate the ephemeral keypair and use it to compute the ephemeral-static (C_e/S_s) shared secret. These are necessary to encrypt the client identity. If the client has no information about the server's preferences, then it may send an initial ClientHello without any key share values so that it can learn which curve and server PSK identity to use when generating the client ephemeral key.
If the above precomputations are performed, then during the handshake the client only needs to perform one (respectively, two) public key operations for 2(EC)DH (respectively, 3(EC)DH) authenticated key agreement. These values are reduced by one for anonymous clients, but constrained devices are not expected to use this mode.
Some changes are made to the key schedule which is specified in section 7.1 of [I-D.ietf-tls-tls13] when computing keys generated using the 2/3(EC)DH mode of key exchange. These changes introduce a new derived secret which is used as a basis for encrypting client PSK identities as well two new labels which are used for generating bindings for the new PSK identities. Also, the schedule inputs are expanded to introduce multiple (EC)DH shared keys, which are the basis for this mode's authenticated key agreement.
In addition, there is a new key calculation which is used to encrypt the client PSK identity.
The key schedule shown below uses the same formatting conventions and functions as used in section 7.1 of [I-D.ietf-tls-tls13]. That is,
Authenticated key agreement using 2(EC)DH or 3(EC)DH makes use of both static and ephemeral (EC)DH keys, and these keys may belong to either the client or the server. This results in four possible ways to combine a client key with a server key. These are shown in the key schedule as follows:
The concatenation of two octet strings is shown using || between the strings.
Server PSK Identity ||
Server Static (EC)DH Public Key
|
V
C_e/S_s -> HKDF-Extract = Client Id Secret
|
+-----> Derive-Secret(., "client id",
| Truncate(ClientHello))
| = client_id_secret
|
Derive-Secret(., "derived", "") | /* 2/3(EC)DH */
0 /* not 2/3(EC)DH */
|
v
PSK | -> HKDF-Extract = Early Secret /* not 2/3(EC)DH */
C_s/S_s | /* 2/3(EC)DH */
+-----> Derive-Secret(.,
| "ext binder" |
| "res binder" |
| "2dh binder" | /* 2(EC)DH */
| "3dh binder", /* 3(EC)DH */
| "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic",
| ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master",
| ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
(EC)DHE | v /* not 2/3(EC)DH */
C_s/S_e | --> HKDF-Extract = Handshake Secret /* 2(EC)DH */
(C_e/S_e || | /* 3(EC)DH */
C_s/S_e) +-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_master_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_master_secret
(EC)DH computations can leak information about the private key if the peer public key is not valid. Therefore, all (EC)DH computations in the key schedule MUST be preceded by a validity check on the peer public key as described in section 4.2.8.1 or section 4.2.8.2 of [I-D.ietf-tls-tls13]; additional validity checks may be added as new attacks are discovered. The endpoint MUST terminate the handshake if validation fails. Validation is required even for the static public keys, as the security of these keys is likely to be lower than for the static private key, and they may be manipulated by an attacker even if validation takes place during provisioning.
The first change to the key schedule defined in [I-D.ietf-tls-tls13] introduced to support 2/3(EC)DH is to prepend an HKDF-Extract computation to generate the Client Id Secret. The salt for this computation is the concatenation of the server PSK identity with the corresponding static public key; the IKM is the secret generated by the client ephemeral key and the server static key. For 2/3(EC)DH modes of key agreement, the salt for the next step of the key schedule is a secret derived from the Client Id Secret; for other modes the salt is a zero block. This means that this specification results in no change to the key schedule for all other modes.
Next, the IKM for the generation of the Early Secret for 2/3(EC)DH is the secret which is generated by the client static key and the server static key. This is a long-term secret which is equivalent to the PSK which is the IKM for other PSK modes. The inclusion of keying material based on the client static (EC)DH key provides data origin authenication for 0-RTT traffic (if present). For anonymous clients, this IKM is a zero block; data origin authentication has no meaning in any case for anonymous clients.
Additional labels are defined for the generation of the binder_key which is used to bind the identity and key to the current handshake. The label "2dh binder" (respectively "3dh binder") is used if the selected mode is 2(EC)DH (respectively 3(EC)DH).
The last change to the key schedule is to the IKM used to derive the Handshake Secret. As defined in [I-D.ietf-tls-tls13], this is the secret generated by the client ephemeral key and the server ephemeral key (if available). For 2(EC)DH, this is the secret generated by the client static key and the server ephemeral key. For 3(EC)DH, this is the concatenation of the secrets generated by the client ephemeral key and the server ephemeral key, and by the client static key and the server ephemeral key in that order.
All (EC)DH computations are carried out as described in section 7.4 of [I-D.ietf-tls-tls13].
Each offered client PSK identity within a handshake is associated with a different server PSK identity, which means that the key schedule ensures that a different Client Id Secret is computed for each identity. This means that each derived client_id_secret is different within a handshake.
However, it is possible that a client may re-use an ephemeral key in multiple handshakes (though this is bad practice). If the client pads the identity differently or manages multiple identities then this will leak identity information. Therefore, the truncated handshake context is included in the computation of the client_id_secret to mitigate possible ephemeral key reuse.
The Truncate() function which is used when computing client_id_secret is similar to that used in computing the binding values (see section 4.2.11.2 of [I-D.ietf-tls-tls13]), except that it excludes the entire "pre_shared_key" extension, instead of just removing the binders list. If the ClientHello is sent in response to a HelloRetryRequest then the Truncate() function only applies to the second ClientHello; the full first ClientHello message is included in the Transcript-Hash as defined in section 4.4.1. of [I-D.ietf-tls-tls13].
The encrypted identity is integrity-protected by the corresponding PSK binder, so only encryption is required. Therefore, the HKDF-Expand-Label function is used to generate a keystream of the same length as the padded client PSK identity and the two are XORed together to produce the encrypted identity. The decryption procedure is identical.
client_id_key = PKDF-Expand-Label(client_id_secret,
"client id",
length(padded client PSK identity))
This document is based on [I-D.putman-tls-preshared-ecdh] and the author would like carry over the acknowledgements to this document; that is, to thank the authors of [RFC4279], namely Pasi Eronen, Hannes Tschofenig, Mohamad Badra, Omar Cherkaoui, Ibrahim Hajjeh and Ahmed Serhrouchni; and to thank the author of [I-D.harkins-tls-dragonfly], Dan Harkins, for the idea of encrypting the client identity.
This document does not define any new IANA considerations.
The security considerations in [I-D.ietf-tls-tls13] apply to this document as well.
The Double- and Triple-Diffie-Hellman authenticated key exchange is not particularly new, but it has not seen wide usage. Triple-ECDH is used in the Signal protocol and a security proof of both, in a modified form of the Bellare-Rogaway model, is provided in [Kudla]; this latter paper also proves strong partnering in the random oracle model.
The TLS 1.3 protocol is more complex than the protocol used in the above proof, but no additional constraints are made on the components of the proof if the client is not anonymous. All the material which is used to compose the key in the proof is also used in constructing the Finished messages, with the exception of the pair of static keys: instead of including both static keys in the key schedule, the derived secret is included; this is equivalent and is done to give extra protection against weak ephemeral keys. The security proof therefore also holds for the protocol described in this document if the client is not anonymous.
If the client is anonymous, then there is no static client (EC)DH keypair. The security properties of this situation are similar to those of DHIES/ECIES, which also derives a key from a combination of an ephemeral and a static (EC)DH key. The inclusion of handshake context in the generation of all session keys protects against replay attacks, and the inclusion of the ephemeral-ephemeral key in the 3(EC)DH anonymous client situation additionally provides PFS in this exchange. However, none of this is rigorous, and a full security analysis of this should be undertaken.
The security of the 0-RTT traffic has the same weakened conditions as for 0-RTT traffic in other PSK situations, namely that there is no PFS and there is no guarantee of traffic uniqueness.
The confidentiality of the client identity in a genuine handshake is protected by an ephemeral-static shared secret; this has similar properties to DHIES/ECIES. The integrity of the key is protected by the binder.
The encrypted client PSK identity does not have any verified client information in the keying material. Therefore an attacker who knows the server public key may impersonate a client when sending a client key exchange message; this is no different to the other PSK key exchange modes and does not affect the security of the completed handshake.
Because a PSK Identity can be forged, the server should ensure that there are no PSK Identity retrievals which are more expensive than other operations in this protocol; this is to mitigate DoS attacks. Additionally, if there are differences in the lookup time of a PSK Identity (e.g. if recent lookups are cached), then an attacker may be able to obtain information about the PSK Identity of a recent handshake from timing attacks.
This key exchange mode allows for the inclusion of 0-RTT traffic from a client which has no previous communications with the server, only an out-of-band method of obtaining the server PSK information (identity, public key, anonymous client support). This supports rapid client authentication at the application level, for example by using an authentication token. However, there is currently no way to convey this information to the TLS server, which will continue to consider the client to be anonymous. Further work would be needed before this use case could be considered to be secure, and it is not considered further in this document.
As with the other PSK key exchange modes, these modes make use of hidden information in the construction of the keying material. This means that the cipher suites are quantum-safe in the event that the message exchange is stored for later attack, provided that the client and/or server static public keys (the pre-provisioned keys) remain unknown to the eavesdropper. In the anonymous client use case, the server public keys is likely to be widely known, so this observation does not apply.
The protocol description in this document only refers to finite field and elliptic curve Diffie-Hellman keys, but will work for any key exchange mechanism which uses public/private keypairs to establish a shared secret. The only change that is needed to support new methods (which may include quantum-safe key exchange algorithms) is to include their definition in the "key_share" extension. Any new mechanisms which are added to the "key_share" extension MUST include a consideration of their effect on this document in their security section.
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-23, January 2018. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3629] | Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |