idnits 2.17.1 draft-green-tls-static-dh-in-tls13-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 189 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Green 3 Internet-Draft Cryptography Engineering LLC 4 Intended status: Informational October 31, 2016 5 Expires: May 1, 2017 7 Data Center use of Static Diffie-Hellman in TLS 1.3 8 10 Abstract 12 Unlike earlier versions of TLS, current drafts of TLS 1.3 have 13 instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve 14 Diffie-Hellman as the primary cryptographic key exchange mechanism 15 used in TLS. This document describes an optional configuration for 16 TLS servers that allows for the use of a static Diffie-Hellman secret 17 for all TLS connections made to the server. Passive monitoring of TLS 18 connections can be enabled by installing a corresponding copy of this 19 key in each monitoring device. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 Unlike earlier versions of TLS, current drafts of TLS 1.3 [draft- 54 ietf-tls-tls13-18] do not provide support for the RSA handshake -- 55 and have instead adopted ephemeral-mode Diffie-Hellman and elliptic- 56 curve Diffie-Hellman as the primary cryptographic key exchange 57 mechanism used in TLS. 59 While ephemeral (EC) Diffie-Hellman is in nearly all ways an 60 improvement over the TLS RSA handshake, it has a limitation in 61 certain enterprise settings. Specifically, the use of ephemeral (PFS) 62 ciphersuites is not compatible with enterprise network monitoring 63 tools such as Intrusion Detection Systems (IDS) that must passively 64 monitor intranet TLS connections made to endpoints under the 65 enterprise's control. This includes TLS connections made from 66 enterprise load balancers at the edge of the enterprise network to 67 internal enterprise TLS servers. It does not include TLS connections 68 traveling over the external Internet. 70 Such monitoring is ubiquitous and indispensable in some industries, 71 and loss of this capability may slow adoption of TLS 1.3. 73 This document describes an optional configuration for TLS servers 74 that allows for the use of a static Diffie-Hellman secret for all TLS 75 connections made to the server. Passive monitoring of TLS connections 76 can be enabled by installing a corresponding copy of this key in each 77 monitoring device. 79 An advantage of this proposal is that it can be implemented using 80 software modifications to the TLS server only, without the need to 81 make changes to TLS client implementations. 83 2. Summary of the existing Diffie-Hellman handshake 85 In TLS 1.3, servers exchange keys using two primary modes, Ephemeral 86 Diffie-Hellman (DHE) and Elliptic Curve Ephemeral Diffie-Hellman 87 (ECDHE). In a simplified view of the full handshake, the following 88 steps occur: 90 1. The client generates an ephemeral public and private key, 91 and transmits the public key within a "key_share" message, 92 along with a random nonce (ClientHello.random). 93 2. The server generates an ephemeral public and private key, 94 and transmits the public key within a "key_share" message, 95 along with a random nonce (ServerHello.random). 96 3. The two parties now calculate a shared (EC) Diffie-Hellman 97 secret by combining the other party's ephemeral public key 98 with their own ephemeral secret. 99 4. A series of traffic and handshake keys is derived by 100 combining this shared secret with various inputs from the 101 handshake, including the ClientHello.random and 102 ServerHello.random. 103 5. Data encryption is performed using these keys. 105 3. Using static (EC) Diffie-Hellman on the server 107 The proposal embodied in this draft modifies the standard TLS 108 handshake summarized above in the following ways. 110 First, for each elliptic curve (and FF-DH parameter length) supported 111 by the server, the server is provisioned with a random static (EC) 112 Diffie- Hellman private key. This key is generated at server 113 installation, and is rotated at periodic intervals appropriate for 114 any long-term server key. These keys could also be generated at a 115 central key management server and distributed (in a secure encrypted 116 form) to many endpoint servers. 118 The static secret key is used to derive a fixed, static (EC) Diffie- 119 Hellman public key. 121 All steps of the original handshake proceed as above, with the 122 following modification to server behavior. Step (2) proceeds as 123 follows: 125 2. The server transmits the static public key within a "key_share" 126 message, along with a random nonce (ServerHello.random). 128 4. Security considerations 130 We now consider the security implications of the change described 131 above: 133 i. The shift from fully-ephemeral (EC) Diffie-Hellman to partially 134 static Diffie-Hellman affects the security properties offered by 135 the TLS 1.3 handshake by eliminating the Perfect Forward Secrecy 136 (PFS) property provided by the server. If a server is compromised 137 and the private key is stolen, then an attacker who observes any 138 TLS handshake (even one that occurred prior to the compromise) 139 will be able to recover traffic encryption keys and will be able 140 to decrypt traffic. 142 ii. As long as the server static secret key is not compromised, the 143 resulting protocol will provide strong cryptographic security, as 144 long as the Diffie-Hellman parameters (e.g., finite-field group or 145 elliptic curve) are correctly generated and provide security at a 146 sufficient cryptographic security level. 148 iii. Replay attacks are prevented due to the fact that the server 149 generates a unique 32-byte ServerHello.random field using a strong 150 random number generator, and this value is included in the traffic 151 key derivation procedure. 153 iv. A flaw in the generation of finite-field Diffie-Hellman 154 parameters or the use of an insecure implementation could leak 155 some bits of the static secret key over time. This risk is not 156 present in ephemeral DH implementations. Implementers should use 157 care to avoid such pitfalls. 159 Thus the modification described in Section 4 represents a deliberate 160 weakening of some security properties. Implementers who choose to 161 include this capability should carefully consider the risks to their 162 infrastructure of using a handshake without PFS. Static secret keys 163 should be rotated regularly. 165 5. IANA Considerations 167 This document contains no actions for IANA. 169 6. Acknowledgements 171 This modification to TLS was initially suggested by Hugo Krawczyk. 173 7. Normative References 175 [draft-ietf-tls-tls13-18] 176 E. Rescorla, "The Transport Layer Security 177 (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-18 178 (work in progress), October 2016. 180 Author's Address 182 Matthew Green 183 Cryptography Engineering LLC 184 4506 Roland Ave 185 Baltimore, MD 21210 186 USA 188 Email: mgreen@cryptographyengineering.com