idnits 2.17.00 (12 Aug 2021) /tmp/idnits23767/draft-rhrd-tls-tls13-visibility-01.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: ---------------------------------------------------------------------------- No issues found here. 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 (March 2, 2018) is 1534 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 365, but not defined == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 ** Downref: Normative reference to an Informational RFC: RFC 5869 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Standards Track R. Droms 5 Expires: September 3, 2018 Google 6 March 2, 2018 8 TLS 1.3 Option for Negotiation of Visibility in the Datacenter 9 draft-rhrd-tls-tls13-visibility-01 11 Abstract 13 Current drafts of TLS 1.3 do not include the use of the RSA 14 handshake. While (EC) Diffie-Hellman is in nearly all ways an 15 improvement over the TLS RSA handshake, the use of (EC)DH has impacts 16 certain enterprise network operational requirements. The TLS 17 Visibility Extension addresses one of the impacts of (EC)DH through 18 an opt-in mechanism that allows a TLS client and server to explicitly 19 grant access to the TLS session plaintext. 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 https://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 This Internet-Draft will expire on September 3, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 Unlike earlier versions of TLS, current drafts of TLS 1.3 56 [I-D.ietf-tls-tls13] do not provide support for the RSA handshake -- 57 and have instead adopted ephemeral-mode Diffie-Hellman (DHE) and 58 elliptic-curve Diffie-Hellman (ECDHE) as the primary cryptographic 59 key exchange mechanism used in TLS. 61 While ephemeral (EC) Diffie-Hellman is in nearly all ways an 62 improvement over the TLS RSA handshake, the use of these mechanisms 63 has impacts on certain enterprise operational requirements. 64 Specifically, the use of ephemeral ciphersuites prevents the use of 65 current enterprise network monitoring tools such as Intrusion 66 Detection Systems (IDS) and application monitoring systems, which 67 leverage the current TLS RSA handshake to passively decrypt and 68 monitor intranet TLS connections made between endpoints under the 69 enterprise's control. This traffic includes TLS connections made 70 from enterprise network security devices (firewalls) and load 71 balancers at the edge of the enterprise network to internal 72 enterprise TLS servers. It does not include TLS connections 73 traveling over the external Internet. 75 Such monitoring of the enterprise network is ubiquitous and 76 indispensable in some industries, and is required for effective and 77 safe operation of their enterprise networks. Loss of this capability 78 may slow adoption of TLS 1.3 or force enterprises to continue to use 79 outdated and potentially vulnerable technology. 81 The TLS Visibility Extension provides an option to enable visibility 82 into a TLS 1.3 session by an authorized third party. Use of the 83 extension requires opt-in by the TLS client when it initiates a TLS 84 1.3 session. The TLS server then opts-in by including keying 85 material that will enable decryption in the TLS Visibility Extension. 86 The presence of the TLS Visibility Extension provides a clear 87 indication that other parties have been granted access to the TLS 88 session plaintext. The keying material in the TLS Visibility 89 Extension is encrypted and can only be decrypted by authorized 90 parties that have been given the private key from a managed Diffie- 91 Hellman key pair. 93 2. Terminology 95 Two key pairs are used with the TLS Visibility Extension for 96 encryption of the session secrets: 98 SSWrapDH1: generated externally and the public key is provided to 99 the TLS 1.3 server prior to use of the TLS Visibility Extension; 100 the corresponding private key is provided to the parties that are 101 authorized to access the TLS session plaintext. 103 SSWrapDH2: an ephemeral key pair that is generated by the TLS 1.3 104 server for each TLS 1.3 session that uses the TLS Visibility 105 Extension; the server keeps the private key confidential, and 106 passes the public key to the other parties in the TLS Visibility 107 session. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Extension Overview 115 Prior to the use of the TLS Visibility Extension, the SSWrapDH1 key 116 pair is generated, possibly by an enterprise key manager. The 117 private key is passed to the parties that are authorized to access 118 the TLS session plaintext. The server is provisioned with the public 119 key. When a new TLS 1.3 session is initiated, the client includes an 120 empty TLS Visibility Extension in the ClientHello. The server then 121 generates a SSWrapDH2 ephemeral key pair. The server will then: 123 o Generate a key, Ke, from the SSWrapDH1 public key and the 124 SSWrapDH2 private key. 126 o Encrypt the TLS 1.3 session Early Secret (if one exists) and 127 Handshake Secret (session secret) using Ke. 129 o Send an identifier for the SSWrapDH1 public key (called the 130 fingerprint), the SSWrapDH2 public key, and the encrypted session 131 secrets in the TLS Visibility Extension in the ServerHello 132 message. 134 To decrypt the TLS 1.3 session, a party that is authorized to access 135 the TLS session plaintext must be given the SSWrapDH1 private key. 136 The party then: 138 o Obtains the SSWrapDH1 public key from the TLS Visibility extension 139 o Uses the SSHWrapDH1 private key and the SSWrapDH2 public key to 140 generate Ke 142 o Uses Ke to decrypt the session secrets carried in the TLS 143 Visibility extension 145 o Uses the session secrets to derive the keying material needed 146 decrypt the TLS 1.3 session 148 4. TLS Visibility Extension 150 This section specifies the "tls_visibility" extension, which is 151 carried in the ClientHello message and the ServerHello message. 153 The general extension mechanisms enable clients and servers to 154 negotiate the use of specific extensions. As specified in 155 [I-D.ietf-tls-tls13], clients request extended functionality from 156 servers with the extensions field in the ClientHello message. If the 157 server responds HelloRetryRequest, then the client sends another 158 ClientHello message that includes the same extensions field as the 159 original ClientHello message. 161 Most server extensions are carried in the EncryptedExtensions 162 message; however, the "tls_visibility" extension is carried in the 163 ServerHello message in a manner similar to the "key_share" and 164 "pre_shared_key" extensions. It is only present in the ServerHello 165 message if the server wants to enable TLS Visibility for some other 166 parties and the client has offered the "tls_visibility" extension in 167 the ClientHello message. 169 The "tls_visibility" extension MAY appear in the CH (ClientHello 170 message) and SH (ServerHello message). It MUST NOT appear in any 171 other messages. The "tls_visibility" extension MUST NOT appear in 172 the ServerHello message unless "tls_visibility" extension appeared in 173 the preceding ClientHello message. If an implementation recognizes 174 the "tls_visibility" extension and receives it in any other message, 175 then the implementation MUST abort the handshake with an 176 "illegal_parameter" alert. 178 The Extension structure is defined in [I-D.ietf-tls-tls13]; it is 179 repeated here for convenience. 181 struct { 182 ExtensionType extension_type; 183 opaque extension_data<0..2^16-1>; 184 } Extension; 186 The "extension_type" identifies the particular extension type, and 187 the "extension_data" contains information specific to the particular 188 extension type. 190 This document specifies the "tls_visibility" extension type, adding 191 one new type to ExtensionType: 193 enum { 194 tls_visibility(TBD), (65535) 195 } ExtensionType; 197 The "tls_visibility" extension is relevant when the client and server 198 choose to enable one or more other parties to decrypt the TLS 199 session. 201 Clients MUST include the "tls_visibility" extension in the 202 ClientHello message to indicate their willingness for other parties 203 to decrypt the TLS session. The server responds with data that 204 enables the other parties to derive the keying material needed to 205 decrypt the session if they are in possession of the indicated ECDH 206 private key. 208 struct { 209 select (Handshake.msg_type) { 210 case client_hello: Empty; 211 case server_hello: WrappedSessionSecrets visibility_data; 212 }; 213 } TLSVisibilityExtension; 215 struct { 216 opaque early_secret<1..255>; 217 opaque hs_secret<1..255>; 218 } SessionSecrets; 220 struct { 221 opaque fingerprint<20>; 222 opaque key_exchange<1..2^16-1>; 223 opaque wrapped_secrets<1..2^16-1>; 224 } WrappedSessionSecrets; 226 The fields in WrappedSessionSecrets are used as follows: 228 o "fingerprint" contains the leftmost 20 octets of the SHA-256 hash 229 of SSWrapDH1 public key that was used by the server to compute the 230 session secret wrapping key. The public key is DER-encoded in the 231 SubjectPublicKeyInfo [RFC5280] for the SHA-256 hash computation. 232 The key manager tells the server which AEAD algorithm to use with 233 this SSWrapDH1 public key at the time it is distributed. 235 o "key_exchange" contains the SSWrapDH2 ephemeral public key 236 generated by the server on the same elliptic curve as the 237 SSWrapDH1 public key identified by the "fingerprint". The server 238 uses the SSWrapDH2 ephemeral private key and the SSWrapDH1 public 239 key identified by the "fingerprint" to compute a shared secret 240 value, called Z, and then uses HKDF [RFC5869] to produce the 241 session secret wrapping key, called Ke, and an AEAD nonce, if one 242 is needed by the AEAD algorithm [RFC5116]. The details of the key 243 agreement process are described in Section 5. 245 o "wrapped_secrets" contains the SessionSecrets structure encrypted 246 with the AEAD algorithm under Ke. The details of the encryption 247 process are described in Section 5. 249 The fields in SessionSecrets are used as follows: 251 o "early_secret" contains the Early Secret that was derived from the 252 pre-shared key. If this session did not use a pre-shared key, 253 then the Early Secret is HKDF-Extract(0, 0). 255 o "hs_secret" contains the handshake key that was computed using 256 (EC)DHE. 258 5. Session Secret Wrapping 260 The input to the encryption process is the encoded SessionSecrets 261 structure, and the ciphertext is carried in the "wrapped_secrets" 262 field in the WrappedSessionSecrets structure. The session secret 263 wrapping key, called Ke, and an AEAD nonce, if one is needed by the 264 AEAD algorithm [RFC5116] are used to perform the encryption. For 265 example, AES-KEY-WRAP-256 [RFC5649] does not require a nonce, but 266 AES-GCM-128 [GCM] does require a nonce. 268 The "key_exchange" field of the WrappedSessionSecrets structure 269 contains the SSWrapDH2 ephemeral public key generated by the server 270 on the same elliptic curve as the SSWrapDH1 public key identified by 271 the "fingerprint" field of the WrappedSessionSecrets structure. The 272 server uses the SSWrapDH2 ephemeral private key and the SSWrapDH1 273 public key to compute a shared secret value, called Z, and then uses 274 HKDF [RFC5869] to produce the Ke and the nonce: 276 PRK = HKDF-Extract(0x00, Z) 277 Ke = HKDF-Expand(PRK, "tls_vis_key", AEAD_key_size) 278 nonce = HKDF-Expand(PRK, "tls_vis_nonce", AEAD_nonce_size) 280 The length of the ciphertext can be longer than the input plaintext, 281 depending on the AEAD algorithm that is used. The AEAD algorithm is 282 distributed to the server along with the SSWrapDH1 public key, so 283 there is no need to carry an explicit algorithm identifier. 285 Encryption is performed as follows: 287 wrapped_secrets = AEAD-Encrypt(Ke, nonce, SessionSecrets) 289 Other parties use the SSWrapDH2 ephemeral public key from the 290 "key_exchange" field of the WrappedSessionSecrets structure and the 291 SSWrapDH1 private key that is associated with the "fingerprint" field 292 of the WrappedSessionSecrets structure to compute a shared secret 293 value, called Z. The SSWrapDH1 private key and the AEAD algorithm 294 are obtained in advance. Then, Z is used to produce the Ke and the 295 nonce as specified above. To unwrap the session secrets, decryption 296 is performed as follows: 298 SessionSecrets = AEAD-Encrypt(Ke, nonce, wrapped_secrets) 300 The result is either the plaintext of the SessionSecrets structure or 301 an error indicating that the decryption failed. An integrity check 302 is performed as part of the decrypt operation. 304 6. Alternative Approaches 306 This section captures the rationale for pursuing this approach to TLS 307 visibility instead of the various alternative approaches. 309 Server uses a static Diffie-Hellman key pair: Instead of generating 310 ephemeral Diffie-Hellman key pairs, the server reuses a static 311 Diffie-Hellman key pair. The static private Diffie-Hellman key 312 gets shared with the points that need visibility. While this 313 approach scales, the TLS client is unaware of the sharing. In 314 addition, this enables visibility of data of all clients 315 communicating with the server, versus only those that opt-in to 316 visibility. 318 Export of ephemeral keys: In large enterprises there will be 319 billions of ephemeral keys to export and distribute. Transporting 320 these keys to tools for decryption of packets in real time will be 321 difficult, adding greatly to the complexity of the solution. 323 Export of decrypted traffic from TLS proxy devices: Decrypting 324 traffic only at the edge of the enterprise datacenter does not 325 meet all of the enterprise requirements, which include 326 troubleshooting, fraud detection, and network security monitoring. 327 Further, the number of TLS proxies needed are quite costly, add 328 latency, and increase production risk. 330 Continue to use TLS 1.2 within the enterprise network: TLS 1.2 could 331 be used within the enterprise network (with TLS 1.3 outside) to 332 enable TLS visibility via RSA key transport. However, TLS 1.3 has 333 security improvements over TLS 1.2. At some point in the future, 334 TLS 1.2 will not longer be supported and available in enterprise 335 applications and protocol implementations. In addition, based on 336 experience, standards bodies will deprecate the use of TLS 1.2 and 337 require enterprise networks to move to TLS 1.3. 339 Reliance on TCP/IP headers: TCP and IP headers are not adequate for 340 enterprise requirements. Troubleshooting, fraud detection, and 341 network security monitoring need access to the plaintext payload. 342 For example, troubleshooters must be able to find specific 343 transactions, user identifiers, session identifiers, URLs, and 344 time stamps. 346 Reliance on application and server logs: Logging is not adequate for 347 enterprise requirements. Code developers cannot anticipate every 348 possible problem for logging, and system administrators turn much 349 of the logging off to conserve system resources. 351 Troubleshooting and malware analysis at the endpoint: Endpoints are 352 focused on providing a service, and they cannot handle the 353 additional burden of the various enterprise monitoring 354 requirements. 356 Adding TCP/UDP extensions: An important part of troubleshooting, 357 network security monitoring, etc. is analysis of the application- 358 specific payload of the packet. It is not possible to anticipate 359 ahead of time, among thousands of unique applications, which 360 fields in the application payload will be important. 362 7. IANA Considerations 364 IANA is requested to update the TLS ExtensionType Registry to include 365 "tls_visibility" with a value of [TBD] and the list of messages "CH, 366 SH" in which the "tls_visibility" extension may appear. 368 8. Security Considerations 370 The use of a TLS protocol extension ensures that both the TLS client 371 and the TLS server are aware that other parties have visibility into 372 the TLS session plaintext. However, the approach used here does not 373 allow those parties to masquerade since they do not have the ability 374 to sign the Finished message in the TLS handshake. 376 Use of the TLS Visibility extension represents a deliberate 377 introduction by the client and server of other parties that can 378 access the TLS session plaintext. Deployments that choose to make 379 use of this extension should carefully consider the risks associated 380 with the change to the Forward Secrecy. In particular, Forward 381 Secrecy will not begin for sessions where the TLS Visibility 382 Extension is used until all of these events take place: 384 (1) The server has securely discarded the session secrets. 386 (2) The server has securely discarded the session secret wrapping 387 key. 389 (3) The client has securely discarded the session secrets. 391 (4) The other parties have securely discarded the session secrets. 393 (5) The other parties have securely discarded the session secret 394 wrapping key. 396 (6) The other parties have securely discarded the ECDHE private key 397 that was used to derive the session secret wrapping key. 399 By agreeing to the use of the TLS Visibility extension, the client is 400 aware that the TLS session plaintext will be accessible to any other 401 party that has access to the ECDHE private key that was used to 402 derive the session secret wrapping key. It is envisioned that the 403 server and other parties will all be under a single administrative 404 control; however, the TLS Visibility extension does not guarantee any 405 particular scope for the distribution of the ECDHE private keys. 407 The SSWrapDH1 and SSWrapDH2 key size and parameters MUST be selected 408 to provide the same level (or more) of security as the (EC)DHE key 409 used in the TLS Handshake. Similarly, the Sessions Secret Wrapping 410 key size and algorithm MUST be selected to provide the same level (or 411 more) of security as the AEAD cipher used with the TLS Record 412 protocol. If weaker key sizes, parameters or algorithms are used, 413 the attacker will find it easier to obtain the session secrets from 414 the TLS Visibility extension. 416 9. Acknowledgments 418 Matthew Green was the primary author of 419 [I-D.green-tls-static-dh-in-tls13], which describes an earlier 420 solution to the TLS 1.3 session visibility problem. Nick Sullivan 421 and Richard Barnes suggested the use of client and server opt-in. 422 Peter Wu suggested the use of HKDF-Expand to get a nonce. Nalini 423 Elkins, Steven Fenter, Sinok Lao, Andrew Kennedy, Darin Pettis, Tim 424 Polk, Andrew Regenscheid, Murugiah Souppaya, and Paul Turner 425 contributed through discussion to the development of this document. 427 10. References 429 10.1. Normative References 431 [I-D.ietf-tls-tls13] 432 Rescorla, E., "The Transport Layer Security (TLS) Protocol 433 Version 1.3", draft-ietf-tls-tls13-24 (work in progress), 434 February 2018. 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 442 Housley, R., and W. Polk, "Internet X.509 Public Key 443 Infrastructure Certificate and Certificate Revocation List 444 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 445 . 447 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 448 Key Derivation Function (HKDF)", RFC 5869, 449 DOI 10.17487/RFC5869, May 2010, 450 . 452 10.2. Informative References 454 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 455 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 456 Special Publication 800-38D, November 2007. 458 461 [I-D.green-tls-static-dh-in-tls13] 462 Green, M., Droms, R., Housley, R., Turner, P., and S. 463 Fenter, "Data Center use of Static Diffie-Hellman in TLS 464 1.3", draft-green-tls-static-dh-in-tls13-01 (work in 465 progress), July 2017. 467 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 468 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 469 . 471 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 472 (AES) Key Wrap with Padding Algorithm", RFC 5649, 473 DOI 10.17487/RFC5649, September 2009, 474 . 476 Authors' Addresses 478 Russ Housley 479 Vigil Security, LLC 480 918 Spring Knoll Drive 481 Herndon, VA 20170 482 USA 484 Email: housley@vigilsec.com 486 Ralph Droms 487 Google 488 355 Main Street 489 Cambridge, MA 02142 490 USA 492 Email: rdroms.ietf@gmail.com