Semi-Static Diffie-Hellman Key Establishment for TLS 1.3Mozillaekr@rtfm.comCloudflarenick@cloudflare.comApple Inc.One Apple Park WayCupertino, California 95014United States of Americacawood@apple.com
General
TLS Working GroupInternet-DraftTLS 1.3 specifies a signed Diffie-Hellman
exchange modelled after SIGMA . This design is suitable for
endpoints whose certified credential is a signing key, which is the
common situation for current TLS servers. This document describes
a mode of TLS 1.3 in which one or both endpoints have a certified
DH key which is used to authenticate the exchange.DISCLAIMER: This is a work-in-progress draft and has not yet seen
significant security analysis. Thus, this draft should not be used as
a basis for building production systems.TLS 1.3 specifies a signed Diffie-Hellman
exchange modeled after SIGMA . This design is suitable for
endpoints whose certified credential is a signing key, which is the
common situation for current TLS servers, which is why it was
selected for TLS 1.3.However, it is also possible – although currently rare – for
endpoints to have a credential which is an (EC)DH key. This can happen
in one of two ways:They may be issued a certificate with an (EC)DH key, as specified
for instance in They may have a signing key which they use to generate a delegated
credential containing an (EC)DH key.In these situations, a signed DH exchange is not appropriate, and
instead a design in which the server authenticates via its long-term
(EC)DH key is suitable. This document describes such a design modeled
on that described in OPTLS .This design has a number of potential advantages over the signed
exchange in TLS 1.3, specifically:If the end-entity certificate contains an (EC)DH key, TLS can
operate with a single asymmetric primitive (Diffie-Hellman).
The PKI component will still need signatures, but the TLS stack
need not have one. Note that this advantage is somewhat limited
if the (EC)DH key is in a delegated credential, but that allows
for a clean transition to (EC)DH certificates.It is more resistant to random number generation failures on
the server because the attacker needs to have both the server’s
long-term (EC)DH key and the ephemeral (EC)DH key in order to
compute the traffic secrets. [Note:
describes a technique for accomplishing this with a signed exchange.]If the server has a comparatively slow signing cert (e.g., P-256)
it can amortize that signature over a large number of connections
by creating a delegated credential with an (EC)DH key from
a faster group (e.g., X25519).Because there is no signature, the server has deniability for
the existence of the communication. Note that it could always
have denied the contents of the communication.This exchange is not generally faster than a signed
exchange if comparable groups are used. In fact, if delegated
credentials are used, it may be slower on the client as it has
to validate the delegated credential, though the result
may be cached.The overall protocol flow remains the same as that in ordinary TLS 1.3,
as shown below:As usual, the client and server each supply an (EC)DH share in their
“key_share” extensions. However, in addition, the server supplies a
(signed) static (EC)DH share in its Certificate message, either directly
in its end-entity certificate or in a delegated credential. The client
and server then perform two (EC)DH exchanges:Between the client and server “key_share” values to form an
ephemeral secret (ES). This is the same value as is computed
in TLS 1.3 currently.Between the client’s “key_share” and the server’s static
share, to form a static secret (SS).Note that this means that the server’s static secret MUST be in
the same group as selected group for the ephemeral (EC)DH exchange.The handshake then proceeds as usual, except that:Instead of containing a signature, the CertificateVerify contains
a MAC of the handshake transcript, computed based on SS.SS is mixed into the key schedule at the last HKDF-Extract
stage (where currently a 0 is used as the IKM input).In order to negotiate this mode, we treat the (EC)DH MAC as if it were a
signature and negotiate it with a set of new signature scheme values:When present in the “signature_algorithms” extension or
CertificateVerify.signature_scheme, these values indicate DH MAC with
the specified key exchange mode. These values MUST NOT appear
in “signature_algorithms_cert”.Before sending and upon receipt, endpoints MUST ensure that the
signature scheme is consistent with the ephemeral (EC)DH group
in use.Like signing keys, static DH keys are carried in the Certificate
message, either directly in the EE certificate, or in a delegated
credential. In either case, the OID for the SubjectPublicKeyInfo
MUST be appropriate for use with (EC)DH key establishment. If
in a certificate, the key usage and EKU MUST also be set appropriately
See and [[TBD: P-256, etc.]] for specific
details about these formats.Instead of a signature, the server proves knowledge of the private
key associated with its static share by computing a MAC over the
handshake transcript using SS. The transcript thus far includes all
messages up to and including Certificate, i.e.:The MAC key – SS-Base-Key – is derived from SS as follows:The MAC is then computed using the Finished computation described
in Section 4.4, with SS-Base-Key as the
Base Key value. Receivers MUST validate the MAC and terminate
the handshake with a “decrypt_error” alert upon failure.Note that this means that the server sends two MAC computations in
the handshake, one in CertificateVerify using SS and the other in
Finished using the Master Secret. These MACs serve different
purposes: the first authenticates the handshake and the second proves
possession of the ephemeral secret.The final HKDF-Extract stage of the TLS 1.3 key schedule has
an HKDF-Extract with the IKM of 0. When static key exchange
is negotiated, that 0 is replaced with SS, as shown below.[[OPEN ISSUE]] In principle, we can do client authentication the same way,
with the client’s DH key in Certificate and a MAC in CertificateVerity.
However, it’s less good because the client’s static key doesn’t get mixed
in at all. Also, client DH keys seem even further off.[[OPEN ISSUE: This design requires formal analysis.]]This is intended to have roughly equivalent security properties to current TLS 1.3,
except for the points raised in the introduction.Open questions:Should semi-static key shares be mixed into the key schedule for client authentication?Should we add support for early data encryption using a semi-static key?IANA [SHOULD add/has added] the new code points specified
in to the TLS 1.3 signature scheme registry, with
a “recommended” value of TBD.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Secondary Certificate Authentication in HTTP/2A use of TLS Exported Authenticators is described which enables HTTP/2 clients and servers to offer additional certificate-based credentials after the connection is established. The means by which these credentials are used with requests is defined.Exported Authenticators in TLSThis document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of a certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer.Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key InfrastructureThis document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided.Delegated Credentials for TLSThe organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification.SIGMA: the 'SIGn-and-MAc' approach to authenticated Diffie-Hellman and its use in the IKE protocolsThe OPTLS Protocol and TLS 1.3Randomness Improvements for Security ProtocolsRandomness is a crucial ingredient for TLS and related security protocols. Weak or predictable "cryptographically-strong" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. The Dual EC random number backdoor and Debian bugs are relevant examples of this problem. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol participants to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.