idnits 2.17.1 draft-fenter-tls-decryption-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: ---------------------------------------------------------------------------- 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 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Fenter 3 Intended Status: Informational Enterprise Data Center Operators 4 Expires: September 6, 2018 March 5, 2018 6 Why Enterprises Need Out-of-Band TLS Decryption 7 draft-fenter-tls-decryption-00 9 Abstract 11 Some enterprises are heavily TLS encrypted within their own 12 enterprise network boundaries. Many of these enterprises are also 13 utilizing out-of-band TLS decryption in order to inspect their own 14 traffic for purposes of troubleshooting, network security monitoring, 15 and for other kinds of monitoring. These monitoring functions are 16 mission critical, and cannot just be done without when TLS 1.3 17 (draft-ietf-tls-tls13-26) is released or when the RSA key exchange is 18 someday deprecated from TLS 1.2 (RFC5246). This draft will outline 19 the use cases for out-of-band TLS decryption, as well as alternative 20 suggestions for monitoring and troubleshooting and the limitations of 21 those alternatives. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Out-of-Band Decryption Use Cases for Diagnostics and 63 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1 Application Performance Monitoring . . . . . . . . . . . . 6 65 2.2 Network Diagnostics and Troubleshooting . . . . . . . . . . 6 66 2.2.1 Network Packet Analysis . . . . . . . . . . . . . . . . 6 67 2.2.2 Packet Analysis with Source Address Translation . . . . 7 68 2.2.3 TCP Pipelining - Session Multiplexing . . . . . . . . . 7 69 2.2.4 TLS Encrypted MQ to the mainframe . . . . . . . . . . . 8 70 2.2.5 Application Layer Data . . . . . . . . . . . . . . . . 8 71 2.2.6 Customer Experience Monitoring . . . . . . . . . . . . 9 72 2.2.7 VoIP Analysis . . . . . . . . . . . . . . . . . . . . . 9 73 2.3 Out-of-Band Decryption Use Cases for Network Security 74 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 10 75 2.3.1 Layer 7 DDoS Attacks . . . . . . . . . . . . . . . . . 10 76 2.3.2 Fraud Monitoring . . . . . . . . . . . . . . . . . . . 10 77 2.3.3 Intrusion Detection System . . . . . . . . . . . . . . 11 78 2.3.4 Threat Detection and Incident Response . . . . . . . . 11 79 2.3.5 Regulatory Examples . . . . . . . . . . . . . . . . . . 11 80 2.3.5.1 PCI (Payment Card Industry) . . . . . . . . . . . . 11 81 2.3.5.1.1 PCI and TLS Encryption . . . . . . . . . . . . . 11 82 2.3.5.1.2 Intrusion Detection . . . . . . . . . . . . . . 12 83 2.3.5.1.3 TLS 1.2 and PCI . . . . . . . . . . . . . . . . 12 84 2.3.5.2 e-CFR (Electronic Code of Federal Regulations) . . . 12 85 2.3.5.2.1 Insider Abuse . . . . . . . . . . . . . . . . . 12 86 2.3.5.3 Regulatory Requirements - Summary . . . . . . . . . 13 87 3. Alternative Solutions Offered and Their Limitations . . . . . 13 88 3.1 Inline/MITM Decryption . . . . . . . . . . . . . . . . . . 13 89 3.2 Using TCP or UDP Extensions to Supply Extra Information . . 14 90 3.3 Using IP and TCP Headers for Monitoring and 91 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . 15 92 3.4 TLS 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 3.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 3.6 Troubleshooting at the Endpoint . . . . . . . . . . . . . . 16 95 3.7 Security Monitoring at the Endpoint . . . . . . . . . . . . 16 96 3.8 Encrypted Traffic Inspection . . . . . . . . . . . . . . . 17 97 3.9 IPsec instead of TLS . . . . . . . . . . . . . . . . . . . 17 98 4. An Examination of Arguments Against All Network Decryption . . 18 99 4.1 Technical Arguments . . . . . . . . . . . . . . . . . . . . 18 100 4.1.1 "I work for a large company and we don't have to 101 decrypt packets." . . . . . . . . . . . . . . . . . . . 18 102 4.2 Privacy Arguments . . . . . . . . . . . . . . . . . . . . . 18 103 4.2.1 "It's a violation of personal privacy to decrypt TLS 104 traffic anywhere except at the TLS endpoint." . . . . . 18 105 4.2.2 "Pervasive Monitoring is an Attack" . . . . . . . . . . 19 106 5. Possible TLS 1.3 Decryption Solutions . . . . . . . . . . . 19 107 5.1 Static Diffie Hellman . . . . . . . . . . . . . . . . . . . 19 108 5.2 TLS 1.3 Option for Negotiation of Visibility in the 109 Datacenter . . . . . . . . . . . . . . . . . . . . . . . . 19 110 5.3 Solution Summary . . . . . . . . . . . . . . . . . . . . . 20 111 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 115 9.1 Normative References . . . . . . . . . . . . . . . . . . . 21 116 9.2 Informative References . . . . . . . . . . . . . . . . . . 21 117 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 120 1. Introduction 122 Most enterprise networks originally transmitted packet data in the 123 clear inside their internal networks. Many still do today. When 124 certain enterprises started TLS encrypting their internal networks to 125 protect against insider threat and/or for regulatory compliance 126 reasons, they always had the option of using RSA key exchanges and 127 using static RSA private keys for a small, privileged group to 128 decrypt and inspect their traffic out-of-band. Out-of-band 129 decryption provides ubiquitous packet payload visibility inside the 130 enterprise that cannot be replaced by inline/MITM decryption 131 solutions. Today there are enterprises with extensive packet broker 132 networks who are doing out-of-band TLS decryption to feed network 133 sniffers, intrusion detection devices, fraud detection, malware 134 detection, application performance monitoring tools, customer 135 experience monitoring tools, and other solutions. 137 The capability to do out-of-band decryption has been available for 138 twenty years, and for the first time in history it will be gone with 139 the move to TLS1.3 [TLS13]. A large body of tools has grown up over 140 the last twenty years that is dependent on out-of-band decryption. 141 These tools are performing mission critical functions for 142 enterprises, and the loss of out-of-band decryption will create major 143 operational problems for TLS encrypted enterprises if TLS 1.3 is 144 implemented as-is inside the enterprise. Ubiquitous packet capture 145 and decryption are required for enterprise troubleshooting, and 146 without this capability there will be high severity outages that 147 cannot be solved in an acceptable time frame. The outcome will be 148 the same as extended Denial of Service attacks on enterprises 149 worldwide. Without an out-of-band decryption solution, enterprises 150 are left with the unattractive option of inline/MITM decryption at 151 the data center edge and running traffic with legacy protocols or in 152 the clear throughout the data center if they need packet payload 153 visibility. This opens certain enterprises up to significant 154 regulatory and insider threat problems. There are reasons why other 155 forms of troubleshooting and monitoring do not functionally replace 156 the visibility lost from losing out-of-band TLS decryption. These 157 alternative suggestions are discussed in the sections below. 159 TLS 1.2 [RFC5246] is not a long term option for enterprises. The RSA 160 key exchange is gradually being removed by vendors as a TLS 1.2 161 option. For example, mobile devices have been seen to send TLS 1.2 162 Client Hello's with no RSA key exchange options. There is also the 163 risk that new vulnerabilities and weaknesses will be discovered with 164 TLS 1.2 and/or RSA that will accelerate its removal by other vendors. 166 2. Out-of-Band Decryption Use Cases for Diagnostics and Troubleshooting 168 2.1 Application Performance Monitoring 170 Network-based Application Performance Monitoring requires TLS 171 decryption in order to track application response time by user and by 172 URL, which is the information that the application owners and the 173 lines of business need. The end user IP address is obscured by TLS 174 termination and by source address translation, both on the Internet 175 and within the data center. The identity of the user can only be 176 determined by looking at the payload of the TLS packet. URL 177 identification allows the application support team to do granular, 178 code level troubleshooting and performance monitoring at multiple 179 tiers of an application. 181 2.2 Network Diagnostics and Troubleshooting 183 2.2.1 Network Packet Analysis 185 The key to effective network packet troubleshooting is the ability to 186 follow a transaction through multiple tiers of an application in 187 order to isolate the fault domain. The extensive use of both 188 encryption and source address translation in some enterprises has 189 made it difficult, or even impossible to follow a transaction without 190 the ability to decrypt TLS and examine the payload of the packet. 191 When the payload is available, the packet analyst can find unique 192 identifiers (userids, session ids, etc.) as well as the URL the end 193 user is accessing in order to identify the correct TCP conversation. 195 The packet payload allows analysts to trace the slow or failing 196 transaction above and below firewalls, above and below load 197 balancers, above and below switches, etc., in order to isolate the 198 fault domain. This kind of analysis is not possible from the 199 endpoint alone. There are firewalls and load balancers that do not 200 terminate TLS, and there can be a significant number of 201 infrastructure devices in between the TLS endpoints, any one of which 202 can be the cause of a problem. This above/below analysis across all 203 intermediate infrastructure devices often provides the only insights 204 into where the root problem is introduced. 206 It is noteworthy that adding more inline/MITM decryption solutions to 207 a multi-tiered application environment would increase the need for 208 above/below analysis to rule in or out the inline decryption solution 209 itself as the cause of a problem. The increased complexity of the 210 environment would lead to more failures and longer problem resolution 211 times. 213 Packet payload visibility also allows an analyst to match up a 214 network packet trace with log entries in an application log that give 215 an indication of the problem that occurred. This kind of application 216 level packet tracing could be between bare metal servers, or between 217 two VM's on the same hypervisor. Inline/MITM TLS decryption 218 solutions do not scale for this kind of troubleshooting. As an 219 example, because a problem could hit anywhere, an inline/MITM 220 solution would be needed between every possible pair of VM's in a 221 virtual environment, which could scale into the thousands. This 222 large number of inline/MITM solutions would also create its own 223 problems due to the complexity added to the environment. 225 2.2.2 Packet Analysis with Source Address Translation 227 Content Delivery Networks on the Internet have multiple TLS 228 termination points, and the user's source (client) IP is lost. When 229 tracing a data center's Internet connection, it is not possible to 230 even find the correct TCP conversation for an end user that is having 231 a problem without TLS decryption. The packets must be decrypted and 232 the appropriate HTTP header fields examined in order to find the end 233 user IP address. 235 Within the data center, the source IP for inbound TLS can again be 236 changed multiple times. If a load balancer does not terminate TLS it 237 will NAT the source IP so that return packets will find their way 238 back to the load balancer, and to the correct load balancer in a 239 pair. Alternatively, the load balancer may terminate TLS, and start 240 an independent TLS session to the next layer below. Again, the 241 source IP becomes the load balancer's IP address, and return packets 242 will find their way back to the correct load balancer. 244 Reverse proxies, web servers, app servers, and middleware servers can 245 all terminate TLS and start independent TLS calls to lower layers, 246 each time altering the source (client side) IP of packets, and 247 calling a completely different URL. User sessions are also often 248 sprayed randomly by load balancers to all these devices, and the 249 network troubleshooter is left with no option except to trace all 250 packets at a particular layer, decrypt them all, and look at the 251 payload to find a user session. Servers and infrastructure devices 252 typically don't have the horsepower to trace and decrypt all packets 253 like this, but an out-of-band packet broker/sniffer infrastructure is 254 designed to handle this load, and also provides a centralized 255 location for managing and securing capture files. 257 2.2.3 TCP Pipelining - Session Multiplexing 259 When TCP Pipelining/Session Multiplexing is used, multiple end user 260 sessions share the same TCP connection. For the network 261 troubleshooter, even if he/she could find the correct encrypted TCP 262 connection for an end user, there is no way to tell which packet 263 belongs to which end user without decryption. 265 2.2.4 TLS Encrypted MQ to the mainframe 267 MQ requests to the mainframe are farmed out to multiple processing 268 nodes, and the MQ response comes back asynchronously from any one of 269 those processing nodes. There is no way to find the response to a 270 particular request without looking at identifiers in the payload of 271 the packet. This requires TLS decryption. MQ requests can also pass 272 through many infrastructure devices (i.e. load balancers, firewalls, 273 etc.) before reaching the mainframe. Inline/MITM decryption 274 solutions are not scalable for this environment, because visibility 275 could be needed anywhere along the path. 277 2.2.5 Application Layer Data 279 A decrypted TLS packet contains a wealth of critical troubleshooting 280 information for HTTP (e.g. HTTP requests and return codes) as well as 281 for a number of other protocols. Without this level of information, 282 network troubleshooters are blind, unless the problem is some kind of 283 a basic network problem. Even in the case of network problems, the 284 application level detail is sometimes critical for isolating 285 problems, for example, in the case of an intermittent network 286 slowdown or failure. When looking through millions of packets, 287 transactional/application level detail can help the analyst zero in 288 on the correct location in the trace where a network problem is 289 occurring. 291 It is not enough, though, to look only at the HTTP headers. 292 Applications have been known, for example, to return an HTTP 200 OK, 293 yet contain an error message in the payload of the HTTP response. 294 This can only be seen in the decrypted application layer payload of 295 the packet. 297 Applications also use XML or JSON structures in the payload of the 298 packet to store interesting information like user ids and session 299 IDs. Oftentimes this is the level of information that the 300 application support teams possess ("I sent out a request with this 301 session ID and didn't get a response."). The application team 302 doesn't, however, know where their request went wrong among the many 303 layers of infrastructure, network connections, etc., that their 304 request passes through. The network packet troubleshooters are able 305 to follow the transaction through the many layers of infrastructure 306 if they are able to access the packet payload and find a matching 307 identifier. 309 2.2.6 Customer Experience Monitoring 311 Enterprises involved in online commerce have a business need to 312 monitor customer behavior on their web sites. This monitoring 313 requires TLS decryption of the full packet payload, as any location 314 on the web page can be of interest to the user and to those 315 monitoring user behavior. 317 2.2.7 VoIP Analysis 319 When attempting to monitor and/or troubleshoot user experience within 320 voice and video communications, the ability to understand the 321 signaling (session setup and teardown) is absolutely critical. 322 Session Initiation Protocol (SIP) is among the most commonly used 323 control protocols in the VoIP environment, and increasingly it is 324 being encrypted with TLS. 326 SIP request and response codes, when visible, make it possible for 327 even a novice user to understand the basics of what is being 328 requested and what type of response is being provided (Request: 329 INVITE, Response: 200 OK). The detail available in SIP messages 330 enable a level of analysis difficult to mirror using any other 331 method. The SIP/RTP stream must be decrypted in order to allow 332 analysis of these setup messages. In fact, it is not possible to 333 even find the UDP connections to analyze without decryption of the 334 SIP header, because the IP/port pair is found in an SDP of the SIP 335 signaling packets. 337 Phone endpoints are typically not designed for detailed 338 troubleshooting. Many handsets do not have the ability to output SIP 339 signaling information. Endpoints are also not completely trustworthy 340 in a troubleshooting scenario, and network analysis is needed to 341 verify what is happening on the wire. VoIP calls can also be 342 affected by network conditions. Tracing may be done in different 343 locations to identify the effect the network is having on the VOIP 344 call. An inline/MITM solution doesn't scale for this use case. 346 Session Border Controllers can trace SIP signaling, but tracing is 347 often too resource intensive to run on these devices, as they are not 348 designed to handle the extra load. This means that VOIP analysts 349 need out of band packet capture and decryption solutions which are 350 designed for this purpose. 352 Call quality on the audio RTP stream can be monitored with network 353 based tools, if TLS on the audio stream can be decrypted. This gives 354 the VoIP analyst a view of the problem that they can't get from the 355 endpoints. The audio stream is peer-to-peer communication 356 necessitating many visibility points. Again, an inline/MITM 357 decryption strategy doesn't scale. 359 2.3 Out-of-Band Decryption Use Cases for Network Security Monitoring 361 2.3.1 Layer 7 DDoS Attacks 363 Layer 7 DDoS attacks can involve multiple IPs and source-ports 364 generating traffic very similar to that of genuine users. The only 365 way to identify layer 7 attack traffic is via inspecting fields in 366 the packet payload, which are invisible until the packet is 367 decrypted. 369 Internet based DDoS protection services are not perfect. If they are 370 tuned too tightly they block some legitimate production traffic. If 371 they are tuned too loosely, some attack traffic gets through. In 372 reality, during a DDoS attack some attack traffic usually gets 373 through, and enterprises have to be armed to protect themselves. One 374 of the tools they need is the ability to decrypt Internet TLS traffic 375 so they can block layer 7 DDoS attacks. 377 This decryption could be done by an inline/MITM solution, although 378 there is a possibility that an inline decryption solution could be 379 overwhelmed by a volumetric DDoS attack or by an attack targeting 380 session state, becoming a point of failure. An out-of-band or 381 transparent TLS decryption solution does not carry this risk of being 382 overwhelmed and blocking all legitimate traffic. 384 2.3.2 Fraud Monitoring 386 Fraud monitoring is the monitoring and detection of suspicious 387 activities within, through, or perpetrated against a company. It must 388 be reported to regulatory agencies as required by applicable laws and 389 regulations. Examples of fraud are unauthorized account access and 390 identify theft. Fraud monitoring is a mission critical function for 391 financial institutions, and there are network-based tools performing 392 this function with decrypted TLS packets. If fraud monitoring is 393 down, then it is a severity one problem for critical applications. 395 Fraud monitoring looks at network packets in many locations. An 396 inline/MITM solution in this environment does not scale. 398 One of the major fraud monitoring applications consists of an array 399 of servers, including a database, all talking to each other via TLS. 400 Application errors for this fraud monitoring app need to be analyzed 401 just like any other application, including network packet analysis, 402 and TLS decryption is needed in order to match up log errors with 403 network packets on the wire. 405 2.3.3 Intrusion Detection System 407 IDS inspection looks for known and custom malware signatures, 408 potential attack patterns, and known observables associated to 409 Indicators of Compromise in the payload of TLS packets when 410 decryption is available. IDS inspection for inbound and/or internal 411 TLS sometimes depends on out-of-band TLS decryption, and its 412 effectiveness is severely impacted if decryption is not available. 414 IDS inspection is often a regulatory requirement, for example, for 415 cardholder data environments, of which an enterprise may have many. 416 An inline/MITM TLS decryption solution has scalability problems in 417 this kind of environment. 419 2.3.4 Threat Detection and Incident Response 421 IDS Alerts - Threat Detection teams receive IDS alerts and will 422 analyze decrypted network packet traces in order to verify if the 423 alert was valid or was a false alarm. 425 SQL Injection Attacks - This particular alert also needs manual 426 analysis of packet traces in order to identify if the attack was 427 successful, and if so, what data was returned. 429 Endpoint Monitoring Alerts - These alerts often need to be verified 430 with decrypted packet traces, including identification of the source 431 of the attack on the endpoint. Endpoints are less trustworthy than 432 network monitoring tools, and network monitoring is also needed as a 433 backstop for any failures of monitoring on the endpoint. 435 Manual Hunting - Not all attacks are caught by automated monitoring. 436 Threat Detection teams will do manual hunting for known 437 vulnerabilities with decrypted packet traces. 439 Ubiquitous packet payload visibility can be provided by out-of-band 440 decryption for inbound or internal TLS sessions. Traffic sources for 441 malware can be anywhere within the enterprise or external to the 442 enterprise. An inline/MITM decryption solution doesn't scale. 444 2.3.5 Regulatory Examples 446 2.3.5.1 PCI (Payment Card Industry) 448 2.3.5.1.1 PCI and TLS Encryption 450 The PCI Security Standards Council strongly recommends segmenting the 451 cardholder data environment in order to protect the cardholder 452 systems as well as to limit the scope of PCI assessment (PCI 453 Information Supplement: Guidance for PCI DSS Scoping and Network 454 Segmentation, p. 6). PCI has a concept of "connected to" systems, 455 meaning that any system communicating with a system in the cardholder 456 data environment is drawn into PCI requirements. As a practical 457 reality, large enterprises could not get a PCI assessment completed 458 without segmenting the cardholder data environment with tools like 459 firewalling and encryption of data in transit. This creates the need 460 for TLS decryption in order for those enterprises to do 461 troubleshooting, network security monitoring, and other packet-based 462 analysis in which the clear-text payload must be available. 464 2.3.5.1.2 Intrusion Detection 466 The PCI DSS (Data Security Standard) requires IDS/IPS inspection at 467 the perimeter of the cardholder data environment, as well as at 468 critical points in the cardholder data environment (PCI DSS section 469 11.4). If an organization's monitoring and data loss prevention 470 strategy includes payload inspection, TLS encrypted traffic in these 471 environments must be decrypted. PCI applications have grown up over 472 time, and there may be many cardholder data environments in a data 473 center. Inline/MITM decryption solutions are not scalable for this 474 environment due to cost, introduced latency, and production risk from 475 the more complicated, inline/MITM environment. 477 2.3.5.1.3 TLS 1.2 and PCI 479 When significant vulnerabilities were found in SSL and early TLS in 480 late 2014 (including POODLE), it took the PCI Security Standards 481 Council less than a year to require a migration plan away from these 482 SSL/TLS versions (PCI Information Supplement: Migrating from SSL and 483 Early TLS). Enterprises are at risk that vulnerabilities could be 484 found in TLS 1.2 or in the RSA key exchange, and that PCI will 485 require upgrade to TLS 1.3. There is no guarantee that TLS 1.2 will 486 be available many years into the future. 488 2.3.5.2 e-CFR (Electronic Code of Federal Regulations) 490 2.3.5.2.1 Insider Abuse 492 The United States e-CFR, Title 12, Chapter 1, Part 21 requires that 493 national banks and federal branches and agencies of foreign banks 494 monitor and report on insider abuse. This monitoring looks for 495 criminal behavior like employee fraud, and is a mission critical and 496 legally required function for financial institutions operating in the 497 United States. If potentially illegal or fraudulent activity is 498 detected, a Suspicious Activity Report must be filed with FinCEN (the 499 Financial Crimes Enforcement Network of the US Department of the 500 Treasury). 502 One of the tools for accomplishing this monitoring is a network based 503 tool that uses out-of-band TLS decryption to inspect network packets 504 and analyze user activity. The user endpoint cannot be trusted for 505 this monitoring, as it is controlled by the user being suspected of 506 fraudulent or illegal activity. The loss of out-of-band decryption 507 would be crippling to this monitoring. There are many monitoring 508 points for this tool, and inline/MITM decryption is not a scalable 509 option. Also, these kinds of tools have no need to be inline, and 510 forcing the solution inline adds unnecessary complexity and 511 production risk into a mission critical environment. 513 2.3.5.3 Regulatory Requirements - Summary 515 This section is by no means an exhaustive discussion of all 516 regulatory requirements for all verticals in all countries worldwide. 517 However, it does illustrate the kinds of issues that can come up when 518 a long standing "feature" is eliminated from a network security 519 protocol. 521 3. Alternative Solutions Offered and Their Limitations 523 3.1 Inline/MITM Decryption 525 This is a valid sounding option but presents scalability problems for 526 large, diversified enterprises. 528 TLS decryption for security monitoring is needed in more locations 529 than just everything in and out of the Internet; for example, network 530 security monitoring is done on Business to Business connections, the 531 branch/MPLS head-end, the mainframe, cardholder data environments, 532 wireless controllers, DNS servers, etc. 534 Network troubleshooters need to be able to take traces and decrypt 535 them anywhere in the enterprise network. This can be hundreds or 536 even thousands of locations, depending on the particular problem that 537 hits, and can include the data center, branches, the virtual 538 environment, and public or private clouds. It's not scalable to try 539 and put an inline/MITM decryption solution between any two servers in 540 the enterprise who may be talking to each other via TLS. This could 541 include VM's talking to each other on the same hypervisor or 542 containers talking to each other on the same VM. 544 Cost - Bypass taps and TLS decryption appliances are expensive, and 545 the cost adds up when adequate resiliency and failover is 546 architected. The cost for implementing an inline/MITM decryption 547 strategy can quickly escalate into millions of dollars. 549 Latency - TLS decryption appliances add 1-3 ms of latency per packet 550 in a hardware appliance. Virtual decryption appliances may take a 551 larger latency hit. When multiple inline decryption locations are 552 implemented, the latency becomes prohibitive. 554 Production Risk - Bypass taps and TLS decryption appliances are 555 complicated devices that can and do fail. When an inline/MITM TLS 556 decryption solution fails, production traffic is brought down. An 557 inline/MITM solution is far more complex than putting in passive 558 network taps, which are very simple and almost never fail. 560 Out-of-band TLS decryption is a better design for much of the 561 enterprise. It provides for ubiquitous packet payload visibility 562 with lower cost, no latency, and almost non-existent production risk. 564 Obtaining packets in the virtual and cloud environments is more 565 complex, but an out-of-band TLS decryption solution is still more 566 scalable than inline/MITM TLS decryption everywhere in the virtual or 567 cloud environment. 569 3.2 Using TCP or UDP Extensions to Supply Extra Information 571 This is also an argument that sounds good on the surface and looks 572 like it helps preserve privacy. However, there are a number of 573 reasons why this idea doesn't work in an enterprise. 575 There can be session identifiers in the payload of packets that are 576 needed in order to match up packets (whose source IP may be changing) 577 inside and outside of an infrastructure device, and also to match up 578 application layer requests with application layer responses (the 579 responses don't always ride on the same TCP conversation as the 580 request). These session identifiers are unique to each application, 581 and it is not possible to anticipate, among thousands of 582 applications, which fields in the payload are going to be important 583 for a particular problem. An individual enterprise can have 584 thousands of unique applications. The next enterprise down the road 585 can have thousands more applications of their own, all unique and 586 different from the first enterprise. 588 Software bugs can leave telltale signs in the payload of a packet. 589 These telltale signs are critical pieces of information for 590 troubleshooting difficult problems. It is not possible to 591 anticipate, among thousands of applications, which parts of the 592 payload are going to be important for finding a software bug. 594 Indicators of Compromise can exist anywhere within the payload of a 595 packet. It is not possible to anticipate for every new attack which 596 part of the payload will be important for threat detection and 597 incident analysis. 599 Fields that can be used to block layer 7 DDoS attacks can be anywhere 600 within the payload of the packet. It's not possible to determine 601 which field to block on for any particular DDoS attack until the full 602 payload is decrypted and examined. 604 Customer Experience Monitoring requires full packet payload. A click 605 anywhere on a web page can be of interest to those doing the 606 monitoring. 608 3.3 Using IP and TCP Headers for Monitoring and Troubleshooting 610 This approach has all the same problems as those outlined in section 611 3.2 above. 613 3.4 TLS 1.2 615 No enterprise wants to run an older, less secure version of a 616 protocol for the long term. 618 The RSA key exchange is already in the process of being deprecated 619 from TLS 1.2 in some environments. Examples of this have already 620 been seen in the mobile device environment. 622 Suggestions have been made on the TLS email list that we need to 623 deprecate the RSA key exchange from TLS 1.2. All we need is for 624 another major RSA vulnerability be found, and this sentiment will 625 gain traction. 627 3.5 Logging 629 There are many enterprise outages and slowdowns where there is either 630 no log message on the offending device, or there is a log message 631 that indicates a problem but no clue as to the fault domain or the 632 root cause. Infrastructure devices do not understand layer 7 and so 633 are unable to log meaningful information about a layer 7 transaction 634 that had a problem, even if that particular infrastructure device was 635 the cause of the problem. In many cases, network packet analysis with 636 TLS decryption is required in order to identify the fault domain 637 and/or get to the root cause. 639 It is not possible for a code developer to anticipate every possible 640 problem that is going to occur and put a log message in just the 641 right place. Also, the very nature of a software bug is that the 642 developer doesn't know it's there, so there is not going to be any 643 log message when a bug hits. 645 It is not feasible to go through millions of lines of code in an 646 enterprise environment and "improve" the logging on each device. 648 Between infrastructure and security devices, and application code, 649 this would involve getting hundreds or thousands of vendors to invest 650 and cooperate with this idea. Vendors would have no idea what to log 651 other than what is currently being logged in order to try and catch 652 the "next" problem. 654 Adding log messages after a problem hits is like playing enterprise 655 "Whack-a-mole". The next problem to hit is invariably something 656 completely different. 658 3.6 Troubleshooting at the Endpoint 660 The shortcomings of endpoint logging are covered in section 3.5 661 above. 663 Endpoints in a typical enterprise don't have the robustness to run a 664 full packet capture of all packets, decrypt them all, and keep the 665 trace running all the time. This kind of trace is necessary because 666 analysts don't know which web or app server, for example, is going to 667 be hit for a particular user session, and they don't know when an 668 intermittent problem is going to hit. Instead, enterprises have 669 built up robust, out-of-band packet sniffing devices with TLS 670 decryption capability fed by passive network taps and/or passive 671 mirror ports. 673 Endpoint analysis also misses the crucial troubleshooting function of 674 isolating the fault domain of a problem among many infrastructure 675 devices between the TLS endpoints. 677 3.7 Security Monitoring at the Endpoint 679 Network security monitoring is done by a number of purpose built 680 network devices such as IDS/IPS and security analysis solutions. 681 Network based fraud detection applications can include multiple 682 servers and databases that all communicate with each other. It's not 683 feasible to put all this functionality into an endpoint and have its 684 normal workload unaffected. 686 Endpoints can be overwhelmed by too much security monitoring and 687 their performance impacted. Networks can also be overwhelmed by 688 extensive security reporting from endpoints. As a result, endpoint 689 monitoring is often scaled back to a level that the endpoint and its 690 network connection can handle. 692 Endpoints cannot be completely trusted for network security 693 monitoring. Malware can delete logs and turn off future logging. 694 It's also not always possible to secure data stored on an endpoint, 695 for example, if the endpoint is a laptop and the user packs it up and 696 walks out of the enterprise. The great variety of endpoint types 697 also makes it difficult to implement a consistent monitoring strategy 698 using endpoints alone. 700 Network security monitoring is an important complement to endpoint 701 security monitoring, and is part of a "defense in depth" strategy. 703 3.8 Encrypted Traffic Inspection 705 This technology, while interesting and applicable in some situations, 706 does not fully satisfy the requirements of enterprise traffic 707 inspection. 709 From an application performance and availability perspective, 710 encrypted traffic inspection will not figure out severity one 711 slowdowns or outages, or any other level of problem that may hit an 712 enterprise. Large enterprises have thousands of unique applications 713 that all behave differently at layer 7, and any one of these 714 applications may need layer 7 analysis when a problem hits. This 715 factor of troubleshooting alone is enough to make encrypted traffic 716 inspection an unacceptable, or at least incomplete, solution for 717 enterprise encryption problems. 719 Encrypted traffic inspection does not address fraud detection for 720 either internal or external fraud, both of which look at decrypted 721 TLS packets. 723 Encrypted packet inspection does not address Application Performance 724 Monitoring, Customer Experience Monitoring, or the use of decrypted 725 packets for regulatory compliance monitoring. 727 From a security perspective, encrypted traffic inspection is not 728 going to detect every zero day attack. The parameters it is looking 729 for in the TLS handshake can be varied by new malware. Encrypted 730 traffic inspection, for some methodologies, may be less effective 731 under TLS 1.3 when the handshake is encrypted. 733 Encrypted traffic inspection doesn't take into account the manual, 734 deep packet inspection done by threat detection teams in order to 735 analyze malware alerts, track down their source, and to identify if 736 an attack succeeded or failed. 738 3.9 IPsec instead of TLS 740 The enterprise rollout of internal TLS has been a multi-year project. 741 Enterprises can't just flip a switch and start running IPsec. Moving 742 to IPsec would likely be a multi-year and expensive project. There 743 is extensive manual configuration that would need to be done. 745 There are a number of infrastructure services that don't support 746 IPsec today. For example, IPsec is not supported today by load 747 balancers for data center load balancing services. IPsec is also not 748 supported by Internet proxies for outbound Internet services. 750 A number of new IETF protocols are tied to TLS, including HTTP/2, 751 DPRIVE, and QUIC. Enterprises need a TLS decryption solution in 752 order to support these protocols. 754 4. An Examination of Arguments Against All Network Decryption 756 4.1 Technical Arguments 758 4.1.1 "I work for a large company and we don't have to decrypt 759 packets." 761 Large Internet companies being put forward as examples of promoting 762 encryption are not necessarily encrypted through their entire private 763 enterprise environment as some financial and health care institutions 764 are. 766 There are varying levels of data center depth and complexity between 767 enterprises. Some enterprises have a flatter data center structure, 768 depending on the kinds of services they offer. Other enterprises 769 have many layers to their applications, with multiple layers of 770 infrastructure like firewalls and load balancers, and many layers of 771 middleware, authentication, fraud detection, mainframe, etc. There 772 are also legacy applications that add complexity to the 773 infrastructure, and add to the requirement for decrypted packet 774 payload analysis. 776 Network packet decryption, if it is happening, is likely not visible 777 to all employees within an enterprise. Typically, only select groups 778 within an organization utilize or are aware of this level of detail. 780 As more enterprises in different verticals add TLS decryption inside 781 their data centers, they are going to realize that they also have a 782 need for out-of-band TLS decryption. 784 4.2 Privacy Arguments 786 4.2.1 "It's a violation of personal privacy to decrypt TLS traffic 787 anywhere except at the TLS endpoint." 789 Enterprises have many legitimate business reasons for inspecting 790 their own data, and the IETF should provide them with well studied 791 and standardized options that meet these critical business needs. 793 All TLS data is already being decrypted multiple times in the 794 enterprise data center, and customer data is already available to 795 certain employees of that enterprise. Network packet decryption is 796 just one more decryption of its own data by the same enterprise. 798 4.2.2 "Pervasive Monitoring is an Attack" 800 Pervasive monitoring inside the enterprise has many legitimate use 801 cases, including troubleshooting and network security monitoring. As 802 an example, some applications are too complicated to troubleshoot at 803 the network packet level without advanced preparation of the packet 804 level monitoring, meaning that it takes too much time during a 805 critical outage to get traces set up in all the right places. The 806 answer to this is pervasive monitoring of that application or that 807 environment so that network packet traces, including TLS decryption, 808 are ready when a problem hits. 810 RFC 7258 [RFC7258] should be modified to account for the many 811 enterprise use cases where pervasive monitoring is not an attack. 813 5. Possible TLS 1.3 Decryption Solutions 815 5.1 Static Diffie Hellman 817 Static Diffie Hellman [draft-green] as described in draft-green-tls- 818 static-dh-in-tls13 meets the enterprise need in a manner similar to 819 running RSA key exchanges and using static RSA private keys. 820 Enterprises would be obligated to protect their static keys as they 821 are today in the RSA environment. Draft-green requires no changes to 822 the TLS client, and no changes to the TLS 1.3 spec. It has no impact 823 on the CPU load of the TLS server. Enterprises have the option of 824 rotating their static Diffie-Hellman private keys as often as they 825 see fit. 827 5.2 TLS 1.3 Option for Negotiation of Visibility in the Datacenter 829 TLS 1.3 Option for Negotiation of Visibility in the Datacenter 830 [draft-rhrd] as a solution has some alternative features in 831 comparison to draft-green [draft-green]. It eliminates static 832 Diffie-Hellman private keys from the TLS server as in the case of 833 draft-green. The key manager would only write static private keys 834 from the SSWrapDH1 key pair to the decryption appliances in the 835 protected enterprise network. Draft-rhrd provides for client opt-in 836 and visibility on the wire that traffic payload inspection may be 837 happening. It also allows for decryption in the case of session 838 reuse, which solves a large problem for enterprise monitoring and 839 troubleshooting. It will have some impact on the CPU load of the TLS 840 server. 842 5.3 Solution Summary 844 For both of these solutions, a standard is needed so that all the 845 related systems will interoperate. Draft-green [draft-green] would 846 need to be implemented by multiple TLS server vendors, multiple 847 decryption appliance vendors, and multiple key management solutions. 848 Draft-rhrd [draft-rhrd] would require all of these in addition to 849 implementation by TLS clients. For the above reasons, custom code is 850 a highly unattractive, and possibly unworkable solution. 852 6. Conclusion 854 Out-of-band TLS decryption is used by a number of enterprise tools 855 for mission critical functions, and it supplies ubiquitous packet 856 payload visibility that can't be replaced by other methods. Endpoint 857 analysis is limited by its lack of robustness for analytic 858 activities, by the fact that it can't be completely trusted, and by 859 its blindness to issues in the intervening infrastructure. 860 Inline/MITM decryption adds cost, latency, and production risk at 861 every point it is implemented, and it doesn't scale to meet the 862 requirements of the use cases presented above. 864 7. Security Considerations 866 There are security tradeoffs that enterprises should be allowed to 867 decide. On the one side are the benefits of Forward Secrecy inside 868 the enterprise. On the other side are the benefits of ubiquitous 869 packet payload visibility inside the enterprise. Enterprises are most 870 qualified to make this business decision for themselves, and the TLS 871 Working Group should provide them options rather than making the 872 decision for them. 874 Enterprises choosing to do out-of-band decryption need to continue to 875 implement whatever security controls are appropriate for protection 876 of this decryption environment, including protection of keys, 877 controlling access to the decrypted data, etc. 879 8. IANA Considerations 881 There are no IANA considerations. 883 9. References 885 9.1 Normative References 887 [draft-green] Green, M., Droms, R., Housley, R., Turner, P., and S. 888 Fenter, "Data Center use of Static Diffie-Hellman in TLS 1.3", draft- 889 green-tls-static-dh-in-tls13-01 (work in progress), July 2017. 891 [draft-rhrd] Housley, R. and Droms, R., "TLS 1.3 Option for 892 Negotiation of Visibility in the Datacenter", draft-rhrd-tls-tls13- 893 visibility-01 (work in progress), March 2018. 895 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 896 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 897 2008, . 899 [RFC7258] Farrell, S. and Tschofenig, H., "Pervasive Monitoring Is 900 an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, 901 . 903 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 904 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), March 905 2018. 907 9.2 Informative References 909 Acknowledgments 911 Nalini Elkins, Mike Ackermann, Darin Pettis, and Russ Housley 912 contributed through discussion to the development of this document. 914 Authors' Addresses 916 Steve Fenter 917 Enterprise Data Center Operators, Inc. 918 36A Upper Circle 919 Carmel Valley, CA 93924 921 EMail: info@e-dco.com