TLS clients should reject static Diffie-Hellman
draft-dkg-tls-reject-static-dh-00

Abstract

This draft addresses problematic proposals that contradict the expected security properties of TLS. In particular, the ETSI “Middlebox Security Protocol” standard deliberately weakens the cryptographic guarantees of TLS unilaterally by the server, using static Diffie-Hellman keys where ephemeral keys are expected. Responsible TLS clients should avoid connecting to servers that appear to implement such a specification.

Status of This Memo

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 June 7, 2019.

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 1.1. Key Words
• 2. Problems with static DH
• 2.1. Limited cryptanalysis
• 2.2. Lack of forward secrecy
• 2.3. Confidentiality violation by middleboxes
• 2.4. Message tampering by middleboxes
• 2.5. Session resumption by middleboxes
• 2.6. Static DH implementations are error-prone
• 3. Mitigations against static DH
• 3.1. TLS Clients MUST Reject server certificates marked for use with static DH
• 3.2. Client detection and rejection of static DH
• 3.3. Servers MUST avoid accidental DHE share reuse
• 4. Security Considerations
• 5. Privacy Considerations
• 5.1. Timing of rejection for detecting DH reuse
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

TLS 1.3 [RFC8446] 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.

[draft-green-tls-static-dh-in-tls13-01] 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.

[MIDDLEBOX] was recently formalized by ETSI, and offers a very similar mechanism to [draft-green-tls-static-dh-in-tls13-01]. 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.

1.1. Key Words

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 [RFC2119].

2. Problems with static DH

[MIDDLEBOX] 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.

2.1. Limited cryptanalysis

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.

2.2. Lack of forward secrecy

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.

2.3. Confidentiality violation by middleboxes

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 [MIDDLEBOX] but typical TLS clients unwittingly connecting to such a server may still expect confidentiality against third party eavesdropping. This implementation violates that expectation.

2.4. Message tampering by middleboxes

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.

2.5. Session resumption by middleboxes

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).

2.6. Static DH implementations are error-prone

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

3. Mitigations against static DH

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

3.1. TLS Clients MUST Reject server certificates marked for use with static DH

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

    0.4.0.3523.3.1
    { itu-t(0)
      identified-organization(4)
      etsi(0)
      msp(3523)
      etls(3)
      visibility(1) }

Figure 1: OID of VisibilityInformation `type-id`

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.

3.2. Client detection and rejection of static DH

Annex A of [MIDDLEBOX] 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.

3.3. Servers MUST avoid accidental DHE share reuse

Given the concerns in Section 2 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.

4. Security Considerations

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

5. Privacy Considerations

5.1. Timing of rejection for detecting DH reuse

Clients that are not careful with timing may introduce a minor linkability concern when implementing the mitigation described in Section 3.2.

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.

6. IANA Considerations

There are no IANA considerations for this document.

7. Acknowledgements

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

8. References

8.1. Normative References

8.2. Informative References

Author's Address