Internet DRAFT - draft-dkg-tls-reject-static-dh
draft-dkg-tls-reject-static-dh
tls D. Gillmor
Internet-Draft ACLU
Intended status: Standards Track December 5, 2018
Expires: June 8, 2019
TLS clients should reject static Diffie-Hellman
draft-dkg-tls-reject-static-dh-01
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 8, 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
Gillmor Expires June 8, 2019 [Page 1]
Internet-Draft TLS clients reject static DH December 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems with static DH . . . . . . . . . . . . . . . . . . . 3
2.1. Limited cryptanalysis . . . . . . . . . . . . . . . . . . 3
2.2. Lack of forward secrecy . . . . . . . . . . . . . . . . . 3
2.3. Confidentiality violation by middleboxes . . . . . . . . 3
2.4. Message tampering by middleboxes . . . . . . . . . . . . 4
2.5. Session resumption by middleboxes . . . . . . . . . . . . 4
2.6. Static DH implementations are error-prone . . . . . . . . 4
3. Mitigations against static DH . . . . . . . . . . . . . . . . 4
3.1. TLS Clients MUST Reject server certificates marked for
use with static DH . . . . . . . . . . . . . . . . . . . 5
3.2. Client detection and rejection of static DH . . . . . . . 5
3.3. Servers MUST avoid accidental DHE share reuse . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Timing of rejection for detecting DH reuse . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Gillmor Expires June 8, 2019 [Page 2]
Internet-Draft TLS clients reject static DH December 2018
[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
Gillmor Expires June 8, 2019 [Page 3]
Internet-Draft TLS clients reject static DH December 2018
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 client's old session. The middlebox can
also replay any application-layer data that the server might use to
establish client identity (e.g. passwords, HTTP cookies, or other
bearer tokens).
Since many TLS servers associate client identity with a TLS session
and/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 whether a resuming
client is really the expected client) and replay resistance (because
the middlebox 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. This section documents useful
mitigations.
Gillmor Expires June 8, 2019 [Page 4]
Internet-Draft TLS clients reject static DH December 2018
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.
Gillmor Expires June 8, 2019 [Page 5]
Internet-Draft TLS clients reject static DH December 2018
4. Security Considerations
This entire document is an attempt to address security considerations
associated with the use of static Diffie-Hellman keys in TLS where
ephemeral Diffie-Hellman keys are expected.
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.
Consider a network adversary with the following capabilities:
o can observe some connections
o can actively interfere with other connections
o is willing to cause connection failures in order to link client
sessions
Such an adversary may be able to identify a TLS client of a standard
TLS server across different connections by:
o observing a successul connection, recording the server's
"server_share" value in the "key_share" extension to "ServerHello"
o interfering sith subsequent connections to the same server from
unknown clients
o each interference re-uses the server's previously-offered
"server_share" value.
If the client rejects this repeated share early (e.g upon receipt of
the "ServerHello", but before the handshake completes), then the
network adversary can re-identify the client as being the one that
saw the share recently.
Note that this linkability attack is mitigated by waiting until
handshake completion to reject the server's offer, since a normal
network adversary does not know the server's credentials, so it will
not be able to complete the handshake legitimately. So rejection of
the connection at end of handshake will not allow the server to
distinguish the specific client from any other TLS client.
Gillmor Expires June 8, 2019 [Page 6]
Internet-Draft TLS clients reject static DH December 2018
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
[MIDDLEBOX]
European Telecommunications Standards Institute,
"Middlebox Security Protocol; Part 3: Profile for
enterprise network and data centre access control",
ETSI TS 103 523-3, October 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References
[draft-green-tls-static-dh-in-tls13-01]
Green, M., Droms, R., Housley, R., Turner, P., and S.
Fenter, "Data Center use of Static Diffie-Hellman in TLS
1.3", July 2017.
[invalid-curves-TLS-ECDH]
Jager, T., Schwenk, J., and J. Somorovsky, "Practical
Invalid Curve Attacks on TLS-ECDH", September 2015.
Gillmor Expires June 8, 2019 [Page 7]
Internet-Draft TLS clients reject static DH December 2018
Author's Address
Daniel Kahn Gillmor
ACLU
Email: dkg@fifthhorseman.net
Gillmor Expires June 8, 2019 [Page 8]