Network Working Group M. Green
Internet-Draft Cryptography Engineering LLC
Intended status: Informational October 31, 2016
Expires: May 1, 2017
Data Center use of Static Diffie-Hellman in TLS 1.3
<draft-green-tls-static-dh-in-tls13-00>
Abstract
Unlike earlier versions of TLS, current drafts of TLS 1.3 have
instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve
Diffie-Hellman as the primary cryptographic key exchange mechanism
used in TLS. This document describes an optional configuration for
TLS servers that allows for the use of a static Diffie-Hellman secret
for all TLS connections made to the server. Passive monitoring of TLS
connections can be enabled by installing a corresponding copy of this
key in each monitoring device.
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 http://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."
Copyright Notice
Copyright (c) 2016 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
(http://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.
1. Introduction
Unlike earlier versions of TLS, current drafts of TLS 1.3 [draft-
ietf-tls-tls13-18] do not provide support for the RSA handshake --
and have instead adopted ephemeral-mode Diffie-Hellman and elliptic-
curve Diffie-Hellman as the primary cryptographic key exchange
mechanism used in TLS.
While ephemeral (EC) Diffie-Hellman is in nearly all ways an
improvement over the TLS RSA handshake, it has a limitation in
certain enterprise settings. Specifically, the use of ephemeral (PFS)
ciphersuites is not compatible with enterprise network monitoring
tools such as Intrusion Detection Systems (IDS) that must passively
monitor intranet TLS connections made to endpoints under the
enterprise's control. This includes TLS connections made from
enterprise load balancers at the edge of the enterprise network to
internal enterprise TLS servers. It does not include TLS connections
traveling over the external Internet.
Such monitoring is ubiquitous and indispensable in some industries,
and loss of this capability may slow adoption of TLS 1.3.
This document describes an optional configuration for TLS servers
that allows for the use of a static Diffie-Hellman secret for all TLS
connections made to the server. Passive monitoring of TLS connections
can be enabled by installing a corresponding copy of this key in each
monitoring device.
An advantage of this proposal is that it can be implemented using
software modifications to the TLS server only, without the need to
make changes to TLS client implementations.
2. Summary of the existing Diffie-Hellman handshake
In TLS 1.3, servers exchange keys using two primary modes, Ephemeral
Diffie-Hellman (DHE) and Elliptic Curve Ephemeral Diffie-Hellman
(ECDHE). In a simplified view of the full handshake, the following
steps occur:
1. The client generates an ephemeral public and private key,
and transmits the public key within a "key_share" message,
along with a random nonce (ClientHello.random).
2. The server generates an ephemeral public and private key,
and transmits the public key within a "key_share" message,
along with a random nonce (ServerHello.random).
3. The two parties now calculate a shared (EC) Diffie-Hellman
secret by combining the other party's ephemeral public key
with their own ephemeral secret.
4. A series of traffic and handshake keys is derived by
combining this shared secret with various inputs from the
handshake, including the ClientHello.random and
ServerHello.random.
5. Data encryption is performed using these keys.
3. Using static (EC) Diffie-Hellman on the server
The proposal embodied in this draft modifies the standard TLS
handshake summarized above in the following ways.
First, for each elliptic curve (and FF-DH parameter length) supported
by the server, the server is provisioned with a random static (EC)
Diffie- Hellman private key. This key is generated at server
installation, and is rotated at periodic intervals appropriate for
any long-term server key. These keys could also be generated at a
central key management server and distributed (in a secure encrypted
form) to many endpoint servers.
The static secret key is used to derive a fixed, static (EC) Diffie-
Hellman public key.
All steps of the original handshake proceed as above, with the
following modification to server behavior. Step (2) proceeds as
follows:
2. The server transmits the static public key within a "key_share"
message, along with a random nonce (ServerHello.random).
4. Security considerations
We now consider the security implications of the change described
above:
i. The shift from fully-ephemeral (EC) Diffie-Hellman to partially
static Diffie-Hellman affects the security properties offered by
the TLS 1.3 handshake by eliminating the Perfect Forward Secrecy
(PFS) property provided by the server. If a server is compromised
and the private key is stolen, then an attacker who observes any
TLS handshake (even one that occurred prior to the compromise)
will be able to recover traffic encryption keys and will be able
to decrypt traffic.
ii. As long as the server static secret key is not compromised, the
resulting protocol will provide strong cryptographic security, as
long as the Diffie-Hellman parameters (e.g., finite-field group or
elliptic curve) are correctly generated and provide security at a
sufficient cryptographic security level.
iii. Replay attacks are prevented due to the fact that the server
generates a unique 32-byte ServerHello.random field using a strong
random number generator, and this value is included in the traffic
key derivation procedure.
iv. A flaw in the generation of finite-field Diffie-Hellman
parameters or the use of an insecure implementation could leak
some bits of the static secret key over time. This risk is not
present in ephemeral DH implementations. Implementers should use
care to avoid such pitfalls.
Thus the modification described in Section 4 represents a deliberate
weakening of some security properties. Implementers who choose to
include this capability should carefully consider the risks to their
infrastructure of using a handshake without PFS. Static secret keys
should be rotated regularly.
5. IANA Considerations
This document contains no actions for IANA.
6. Acknowledgements
This modification to TLS was initially suggested by Hugo Krawczyk.
7. Normative References
[draft-ietf-tls-tls13-18]
E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.3", draft-ietf-tls-tls13-18
(work in progress), October 2016.
Author's Address
Matthew Green
Cryptography Engineering LLC
4506 Roland Ave
Baltimore, MD 21210
USA
Email: mgreen@cryptographyengineering.com