TLS clients should reject static Diffie-Hellman

TLS 1.3 promises strong cryptographic properties for a two-party protocol. These properties are the result of extensive engineering and analysis, and are intended to afford users of TLS baseline expectations of confidentiality, integrity, authentication, as well as more subtle properties like replay resistance and forward secrecy. proposed the use of a pseudo-static DH share, and was discussed at length in the IETF TLS working group as a mechanism to modify the security properties of TLS for operations within the “enterprise datacenter”. The working group failed to reach consensus on this draft, in large part because of the changes it created to the TLS security model, the relative lack of cryptanalysis those changes have received, and the risks to users on the broader Internet. was recently formalized by ETSI, and offers a very similar mechanism to . In particular, MIDDLEBOX addresses none of the concerns raised during the earlier discussion, and is not fit for the goals of TLS. This document discusses how responsible TLS clients can avoid the risks inherent in such a design, by refusing connections to peers that implement it.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this docuoment are to be interpreted as described in .

proposes the use of static Diffie-Hellman keys where TLS expects ephemeral Diffie-Hellman keys. Furthermore, it encourages the sharing of those secret keys with third parties (“middleboxes”). This section documents some of the known problems with this design.

TLS 1.3 as specified has been subject to a substantial amount of cryptanalysis, including formal methods that provide security guarantees. Much of that cryptanalysis takes as a given that the ephemeral DH keys are never re-used. Deliberately re-using DH keys invalidates some of this cryptanalysis, and discards the formal guarantees provided.

Standard ephemeral Diffie-Hellman key exchange permits simple forward secrecy by means of each peer discarding the secrets used to establish the session. Reusing a DH key requires retention of the key, which means that the expected forward secrecy properties are lost.

A Middlebox which has access to the DH key of a given session can read the contents of the messages in that session by deriving the client_application_traffic_secret and server_application_traffic_secret and using it to decrypt ApplicationData messages. This appears to be the stated goal of but typical TLS clients unwittingly connecting to such a server may still expect confidentiality against third party eavesdropping. This implementation violates that expectation.

A Middlebox which has access to the DH key of a given session can derive all necessary secrets of the session, and is capable of modifying messages in flight without detection by either peer. This violates the integrity guarantees of TLS.

A middlebox with access to the DH key of a given session can derive the resumption_master_secret, and can also view any NewSessionTicket messages sent by the server. The middlebox can use that information to subsequently resume the session as the client, impersonating the client to the server. The middlebox can also replay any application-layer data that the server might use to establish client identity (e.g. passwords or HTTP cookies). Since many TLS servers associate a TLS session with a client identity or application-layer bearer tokens, this effectively allows the middlebox to impersonate the client. This violates expectations of authenticity (because the server does not know that the client is really the client) and replay resistance (because the server can replay any application layer data sent by the client to the server without the client’s knowledge).

Implementations of static DH schemes are known to be difficult to implement correctly. See for example . Proposals of this nature are likely to introduce new forms of implementation error that would be avoided by standard implementations.

Given the concerns raised in , responsible TLS clients that want to provide the standard TLS guarantees need to implement clear mitigations against risky peers.

suggests that most servers using the designated scheme will use a certificate with so-called “VisibilityInformation” stored in the subjectAltName X.509v3 extension (see ), as an otherName field with a specific type-id of 0.4.0.3523.3.1.

A TLS client that receives a Certificate message from the server where the end entity certificate contains any such element in its subjectAltName MUST terminate the TLS connection with a fatal bad_certificate alert.

Annex A of suggests that some servers may use pseudo-static Diffie-Hellman without this subjectAltName in their certificate. To defend against leakage from these servers, responsible TLS clients that can afford to keep state SHOULD keep track of the DH shares sent by the server over the course of multiple connections. If the TLS client notices that it has been offered the same DH share more than once, it SHOULD terminate the TLS connection upon handshake completion with a fatal decrypt_error alert.

Given the concerns in and the necessary client mitigations in the subsections above, servers need to avoid giving the appearance of using non-ephemeral DH. Servers MUST NOT reuse ephemeral DH shares.

This entire document is an attempt to address security considerations associated with a non-standard use of TLS.

Clients that are not careful with timing may introduce a minor linkability concern when implementing the mitigation described in . A network adversary capable of observing some connections, and actively interfering with others may be able to identify a TLS client of a standard TLS server across different connections by observing a successul connection, and then impersonating the server on a subsequent connection from an unknown client to the same server while re-using the server’s previously-offered DH share. If the client rejects this share early (e.g upon receipt of the ServerHello, but before the handshake completes), then the network adversary can re-identify the client. Note that this likability attack is mitigated by waiting until handshake completion to reject the server’s offer, since a normal network adversary will not be able to complete the handshake legitimately, since it does not know the server’s credentials, so rejection of the connection at that time will not allow the server to distinguish the specific client from any other TLS client.

There are no IANA considerations for this document.

Thanks to numerous commenters on the tls@ietf.org mailing who explained why using static DH presents a risk to TLS users.