idnits 2.17.1 draft-camwinget-tls-proxy-impact-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 04, 2019) is 1625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group N. Cam-Winget 3 Internet-Draft E. Wang 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: May 7, 2020 R. Danyliw 6 Software Engineering Institute 7 R. DuToit 8 Symantec 9 November 04, 2019 11 Impact of TLS 1.3 to Operational Network Security Practices 12 draft-camwinget-tls-proxy-impact-00 14 Abstract 16 Network-based security solutions are used by enterprises, the public 17 sector, internet-service providers, and cloud-service providers to 18 both complement and enhance host-based security solutions. As the 19 most widely deployed protocol to secure communication, these network- 20 based security solutions must necessarily interact with TLS. This 21 document describes this interaction for current operational security 22 practices and notes the impact of TLS 1.3 on them. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 60 3. How TLS is used to enable Network-Based Security Solutions . 4 61 3.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 5 62 3.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via 63 header inspection). . . . . . . . . . . . . . . . . . 5 64 3.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 6 65 3.1.3. OP-3. Crypto and Security Policy Compliance (server) 6 66 3.1.4. OP-4. Crypto and Security Policy Compliance (client) 7 67 3.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 7 68 3.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via 69 payload inspection) . . . . . . . . . . . . . . . . . 8 70 3.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 8 71 3.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 9 72 3.2.4. OP-8: Network-based Threat Protection (client) . . . 9 73 3.2.5. OP-9: Protecting Challenging End Points . . . . . . . 9 74 3.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 10 75 3.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 10 76 3.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 11 77 3.3.2. OP-12. Content distribution and application load 78 balancing . . . . . . . . . . . . . . . . . . . . . . 11 79 3.3.3. OP-13: Network-based Threat Protection (server) . . . 12 80 3.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 12 81 3.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 12 82 4. Changes in TLS v1.3 Relevant to Security Operations . . . . . 13 83 4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 13 84 4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 13 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 7. Appendix A: Summary Impact to Operational Practices with TLS 88 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 Enterprises, public sector organizations, internet service providers 96 and cloud service providers defend their networks and information 97 systems from attacks that originate from inside and outside their 98 networks. These organizations commonly employ security architectures 99 that involve complementary technologies deployed on both endpoints 100 and in the network; and collaborative watch-and-warning practices to 101 realize this defense. 103 The design of these security architectures and associated practices 104 entails numerous trade-offs. Typically, there is more than one 105 technical approach to realize a particular mitigation, although 106 comparable approaches may have different costs or side-effects. 107 Network-based solutions are often attractive because a single network 108 device can: 110 o provide protection to many hosts and systems at once 112 o protect systems regardless of their type (e.g., fully patched 113 desktop systems on a modern operating system; unpatched function- 114 specific industrial control system) 116 o enforce policy on a system even if it is compromised, 117 misconfigured, not under configuration control or had its endpoint 118 protection disabled 120 o be managed (e.g. updates) and provisioned resources (e.g. disk and 121 computing) independent of the systems it is protecting 123 In response to the adoption of new technologies, protocols and 124 threats, these security architectures must evolve to remain 125 effective. [RFC8404] documented such a need with the effect of 126 pervasive encryption on operations. This document takes a narrower 127 focus by documenting the interaction of existing network-based 128 security practices with TLS v1.2 [RFC5246] (and earlier) traffic to 129 implement security policy, detection or mitigation of threats; and 130 the impact on these practices with improvements made in TLS v1.3 131 [RFC8446]. 133 2. Conventions and Definitions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 Specific operational practices are numbered as "OP-##", operational 142 practice 1 (i.e., OP-1), 2 (i.e., OP-2), etc. 144 3. How TLS is used to enable Network-Based Security Solutions 146 Network-based security solutions come in many forms, most commonly as 147 Firewalls, Intrusion Detection Systems (IDS), and Intrusion 148 Prevention Systems (IPS). They inspect the network traffic, and then 149 based on their function, log their observation and/or act on the 150 traffic to implement security policy. When these devices act on the 151 network traffic, they are typically deployed inline, as middleboxes. 152 If their function is only to observe, they can be deployed either as 153 middleboxes or given access to the network traffic out-of-band (OOB), 154 through the network fabric (e.g., network tap or span port). 156 Depending on their function, network-based security devices need 157 different degrees of visibility into the TLS traffic. Some 158 operational practices require only access to the unencrypted protocol 159 headers and associated meta-data of the TLS traffic. Other practices 160 require full visibility into the encrypted session (payload). 162 The practices that inspect only the unencrypted headers and meta-data 163 of TLS, require no special capabilities beyond access to the TLS 164 packets. However, to inspect the encrypted payload of TLS traffic 165 requires a TLS proxy. 167 A TLS proxy provides visibility and inspection to effectuate security 168 controls without changing the state machine of the TLS Server and TLS 169 Client, or the user experience. This TLS Proxy is a transparent hop 170 on the packet path; and where necessary, preserves the client's and 171 server's original IP address and the intended source and destination 172 TCP ports. 174 To achieve this, a TLS Proxy must be able to present a valid X.509 175 certificate to the TLS client to appear as a valid TLS Server; 176 similarly, the client must be able to validate the X.509 certificate 177 using the appropriate trust anchor for that TLS connection. To 178 achieve this, a deployment must properly provision their systems (TLS 179 Proxies and TLS clients). 181 Specific network security operational practices applied to TLS v1.2 182 (and earlier) are described in subsequent sub-sections. They are 183 categorized into the following deployment scenarios: 185 1. Passive TLS inspection, where the network-based security function 186 is inspecting either the inbound or outbound TLS header or meta- 187 data traffic 189 2. Outbound TLS Proxy, where a TLS proxy mediates a TLS session 190 originating from a client inside the perimeter (and in the same 191 administrative domain as the proxy) towards an entity on the 192 outside 194 3. Inbound TLS Proxy, where a TLS proxy mediates a TLS session from 195 a client outside the perimeter towards an entity on the inside 196 (and in the same administrative domain as the proxy) 198 Each deployment scenario describes relevant operational practices. 199 For each operational practice, possible deployment modes (e.g., 200 inline, out-of-band), a description of the practice, and the impact 201 of TLS v1.3 is categorized and explained. The categorized impacts to 202 practices when migrating to TLS v1.3 are as follows: 204 o no impact - no change in capability or performance is expected 205 with this practice 207 o no capability impact - no change in capability is expected; but 208 there may be a performance or implementation change required for 209 this practice 211 o reduced effectiveness - this practice will not be as effective on 212 TLS v1.3 traffic 214 o alternative approach required - this practice will not work with 215 TLS v1.3 traffic 217 3.1. Passive TLS Inspection 219 Passive TLS inspection is the deployment scenario where a network 220 security device passively inspects inbound or outbound TLS traffic to 221 make visibility inferences or take policy actions. The network 222 security device examines only the unencrypted TLS protocol headers 223 and does not have access to the encrypted content of the payload. 225 The TLS proxy deployment scenarios may also incorporate these 226 practices. 228 3.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via header 229 inspection). 231 Deployment mode: inline 233 A firewall or web proxy restricts a client in the same administrative 234 domain from accessing sites or services outside that domain per an 235 acceptable use policy. The identification of the destination server 236 is performed through the inspection of either the SNI field in the 237 TLS ClientHello message from the client; or by extracting the server 238 identity from the Common Name (CN) or Subject Alternative Name (SAN) 239 fields of an X.509 certificate that is presented in the server's 240 Certificate TLS message. This data is used for domain categorization 241 or application identification. 243 This meta-data can also inform decryption eligibility decisions by a 244 firewall, in OP-4. For instance, a firewall may bypass traffic 245 decryption for a connection destined to a healthcare web service due 246 to privacy compliance requirements. 248 TLS 1.3 impact: reduced effectiveness. Per Section 4.2, domain 249 categorization and application identification will be limited to IP 250 address and SNI information (beyond additional correlation possible 251 with other means such as DNS). 253 While an SNI is mandatory in TLS 1.3, there is no guarantee that the 254 server responding is the one indicated in the SNI from the client. A 255 SNI alone, without comparison of the server certificate, does not 256 provide reliable information about the server that the client is 257 attempting to reach. Where a client has been compromised by malware, 258 it may present an innocuous SNI to bypass protective filters (e.g., 259 to reach a command and control server), and this will be undetectable 260 under TLS 1.3. 262 3.1.2. OP-2. Network Behavior Analytics 264 Deployment mode: inline and out-of-band 266 Network behavior analysis and machine learning engines in IDSs, IPSs 267 and firewalls observe the cleartext fields of the TLS handshake 268 (e.g., session cipher suites) and conducts traffic analysis by 269 observing encrypted record sizes, packet rates and their inter- 270 arrival times, and similar outer connection behavior. They match 271 encrypted connections against known application patterns; identify 272 anomalies; and identify or block those without payload inspection. 273 These analytics may also observe that malicious applications may 274 deliberately manipulate certain TLS header fields, throttle packet 275 rates, and vary payload sizes in order to circumvent detection. 277 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, any 278 features relying on Certificate information will not be available. 280 3.1.3. OP-3. Crypto and Security Policy Compliance (server) 282 Deployment: out-of-band 283 A network security device observes TLS handshake traffic to audit 284 that TLS server configuration conforms to policy. This compliance 285 monitoring commonly examines ciphersuites (e.g., use of weak 286 ciphersuites) and certificate properties (e.g., no self-signed 287 certificates, black or white list of certificate authorities, 288 certificate expiration times). 290 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only 291 TLS ClientHello and ServerHello parameters can be audited. 292 Certification information will not be visible. 294 3.1.4. OP-4. Crypto and Security Policy Compliance (client) 296 Deployment: inline 298 A network security device observes TLS handshake traffic to ensure 299 that clients negotiating TLS connections have configurations (e.g., 300 only make connections with TLS 1.2+) and server certificate (e.g., 301 black-listed CAs) that adhere to policy. This is a variant of OP-3. 302 It is commonly used in deployments where an organization may have 303 reduced configuration control of end points (e.g., lab environments, 304 Bring Your Own Device arrangements, and IoT). 306 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only 307 TLS ClientHello and ServerHello parameters can be audited. 308 Certification information will not be visible. 310 3.2. Outbound TLS Proxy 312 Outbound TLS proxy is the deployment scenario where a security device 313 that performs the TLS proxy function is in the same administrative 314 domain as the TLS client, and the TLS server is located in an 315 external zone such as the Internet or in another policy zone of the 316 same administrative domain. Usually the goal is to protect the 317 client endpoint and the organization by controlling application 318 behaviors and enforcing an acceptable use policy for the 319 organizational network. See Figure 1. 321 The administrator manages the TLS client to allow interception by the 322 TLS proxy, usually by deploying a local Certificate Authority (CA) 323 certificate on the TLS client. A typical scenario is an 324 organization-managed client endpoint, such as a laptop or a mobile 325 device that accesses the Internet through the organizational network. 326 When a client attempts to access an external TLS server, the TLS 327 proxy function typically presents a locally signed certificate from 328 the local CA on behalf of the server; alternatively, the certificate 329 generation function may be offloaded to an external Hardware Security 330 Module (HSM) service with which that the TLS proxy must integrate. 332 _________ __________ 333 \ / 334 \ | Administrative 335 \ | Domain, _----__ 336 +-+ \ | Zone 2 / / \____ 337 | | \ \______/ __/ +------+ \ 338 |C|.. | . / |S-NEWS| \__ 339 | | . | . ( +------+ \ 340 +-+ . +---+ . ( +--------+ ) 341 ..| |.... \ |S-GAMING| ) 342 | P |..........( +--------+ ) 343 +-+ ...| | \ +---------+ ) 344 | | . +---+ ( |S-BANKING| / 345 |C|... | \_.+---------+ ) 346 | | | \.. / 347 +-+ / \____--' 348 / 349 Administrative / Internet 350 Domain, Zone 1 / 351 _________/ 353 Figure 1: Outbound TLS proxy 355 3.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via payload 356 inspection) 358 Deployment: inline 360 A firewall or web proxy restricts a client in the same administrative 361 domain from accessing sites or services outside that domain per an 362 acceptable use policy. Similar in intent to OP-1, but the policy 363 enforcement in this practice requires access to data in the TLS 364 session (e.g., URL). 366 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 367 selective decryption policy is used. 369 3.2.2. OP-6: Data Loss Prevention Compliance 371 Deployment: inline 373 A firewall enforces a Data Loss Prevention (DLP) policy by monitoring 374 the TLS sessions content of outbound communication for systems 375 sending organizational proprietary content or other restricted 376 information. 378 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 379 selective decryption policy is used. 381 3.2.3. OP-7: Granular Network Segmentation 383 Deployment: inline 385 A firewall mediates the traffic between different policy zones in an 386 organization. The access policies between these zones may be based 387 on application names and categories rather than static IP addresses 388 and TCP/UDP port numbers. Through a TLS proxy, the firewall can 389 inspect URLs and other application parameters based on data in the 390 TLS session. 392 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 393 selective decryption policy is used. 395 3.2.4. OP-8: Network-based Threat Protection (client) 397 Deployment: inline or out-of-band (depending on functionality) 399 Web proxies and firewalls protect end-users against a range of 400 threats by inspecting the data in the TLS session with a variety of 401 analytical techniques (e.g., signatures, heuristics, statistical 402 models, machine learning). This practice is a superset of OP-2. 403 Common goals are to prevent malware from reaching the endpoint, 404 preventing malware communication from a compromised host, restricting 405 lateral network movement of an intruder and gathering insight into 406 the behavior of threat activity on the network. 408 In certain deployments these technologies are also used to act as a 409 last line of defense against software vulnerabilities on endpoints - 410 either for 0-days for which there is no patch, or simply unpatched 411 clients. 413 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 414 selective decryption policy is used. 416 3.2.5. OP-9: Protecting Challenging End Points 418 Deployment mode: inline 420 Web proxies, IPS and firewalls implement security policy and afford 421 protection to devices for which it is not feasible to run an end- 422 point solution (e.g., IoT); or that are end-of-life and will not 423 receive patches. This is a specialized instance of OP-8 targeting 424 these disadvantaged classes of devices. 426 These practices ensure that that older endpoints (and in some cases 427 even new ones) are not permanently vulnerable to newly discovered 428 vulnerabilities. 430 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 431 selective decryption policy is used. 433 3.2.6. OP-10: Content Injection 435 Deployment: inline 437 A firewall or web proxy restricts insert a message, such as a block 438 page or an interactive authentication portal redirect, into the 439 encrypted flow for the client to see. This may be used in 440 conjunction with OP-1, OP-5, and OP-7. 442 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 443 selective decryption policy is used. 445 3.3. Inbound TLS Proxy 447 Inbound TLS proxy is the deployment scenario where the TLS proxy is 448 deployed in front of one or a set of servers or services. The 449 network device that implements the TLS proxy function is located in 450 the same administrative domain as the server(s) or service(s) it is 451 protecting. Usually it is not predictable or controllable as to 452 which TLS client will initiate a connection. See Figure 2. 454 The TLS proxy is provisioned with the server's certificates and 455 private keys so that it may either decrypt or terminate the TLS 456 connection on behalf of the server. In some instances, the TLS proxy 457 may need to periodically retrieve the private keys and associated 458 certificates from an external secure distribution service, such as a 459 HSM. Traffic between the TLS proxy and server may be encrypted or in 460 the clear; the former configuration is typical of a perimeter 461 firewall while the latter of a load-balancer. 463 ____________ 464 / 465 / S 466 _----__ / .--. 467 / \____ / |==| 468 __/ / |--| 469 / +-+ +-+ \__ | .....|==| S 470 ( | | | | \ | . |--| .--. 471 ( |C| +-+ |C| +-+ ) +---+ . |::| |==| 472 \ | | | | | | | | ) | |... |__| |--| 473 ( +-+ |C| +-+ |C|..............| P | S " " |==| 474 \ | | | | ) | |... .--. |--| 475 ( +-+ +-+ / +---+ . |==| |::| 476 \_. ) | . |--| |__| 477 \.. / | ..|==| " " 478 \____--' \ |--| 479 \ |::| Administrative 480 External Network \ |__| Domain 481 \ " " 482 \____________ 484 Figure 2: Inbound TLS proxy 486 3.3.1. OP-11: TLS offloading 488 Deployment mode: inline 490 Offloads crypto operations from the application server to a TLS 491 Proxy. This is not a typical security function on its own, but it 492 facilitates security control insertion downstream. As this is in the 493 same administrative domain, it is presumed that a TLS Proxy can be 494 provisioned with the appropriate keys when the TLS Server is 495 configured or managed. 497 TLS 1.3 considerations: no impact. 499 3.3.2. OP-12. Content distribution and application load balancing 501 Deployment mode: inline 503 Load balancers deployed in front of services provide resiliency 504 against denial of service attacks. TLS proxy functionality provides 505 access to the cleartext application layer data to enable service- 506 tailored load balancing. Similar to OP-11, it is presumed that a TLS 507 Proxy can be provisioned with the appropriate keys when the TLS 508 Server is configured or managed. 510 This practice may be combined with OP-11. 512 TLS 1.3 considerations: no impact. 514 3.3.3. OP-13: Network-based Threat Protection (server) 516 Deployment mode: inline and out-of-band 518 Web application firewalls (WAF) and firewalls protect servers and 519 services against a range of threats by inspecting the data in the TLS 520 session with a variety of analytical techniques (e.g., signatures, 521 heuristics, statistical models, machine learning). This practice is 522 identical in function to OP-8, but focused on threat prevention of 523 inbound requests to servers and services. 525 TLS 1.3 considerations for inline deployment mode: no capability 526 impact. Per Section 4.1, the network security device must explicitly 527 terminate the TLS connection from the client. 529 TLS 1.3 considerations for out-of-band mode: alternative approach 530 required. Per Section 4.1, active participation in the TLS exchange 531 is required to inspect the session. 533 3.3.4. OP-14: Full Packet Capture 535 Deployment mode: inline and out-of-band 537 A network security device stores a copy of all decrypted traffic that 538 meets a given filter. This traffic may be continuously captured in a 539 rolling buffer for use in future forensic analysis, incident 540 response, or computationally intensive retrospective analysis. This 541 collection may also be selectively enabled to support application 542 troubleshooting. 544 TLS 1.3 considerations for inline deployment mode: no capability 545 impact. Per Section 4.1, the network security device must explicitly 546 terminate the TLS connection from the client. 548 TLS 1.3 considerations for out-of-band mode: alternative approach 549 required. Per Section 4.1, offline decryption is not possible. 551 3.3.5. OP-15: Application Layer Gateway (ALG) 553 Deployment mode: inline 555 To conduct protocol conformance checks and rewrite embedded IP 556 addresses and TCP/UDP ports within the application layer payload for 557 traffic traversing a NAT boundary. While not strictly a security 558 function, this capability may typically be found in firewalls along 559 with the NAT supporting functions. 561 TLS 1.3 considerations: no impact. 563 4. Changes in TLS v1.3 Relevant to Security Operations 565 TLS v1.3 introduces a number of protocol design changes to improve 566 security and privacy. However, these enhancements impact current 567 network security operational practices that rely on the protocol 568 behavior of earlier TLS versions. 570 4.1. Perfect Forward Secrecy (PFS) 572 TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman 573 (DH) cipher suites, which enables the server's private key to be 574 shared with a TLS proxy. TLS 1.3 has removed support for these 575 cipher suites in favor of supporting only ephemeral mode Diffie- 576 Hellman to provide perfect forward secrecy (PFS). As a result of 577 this enhancement, it would no longer possible for a server to share a 578 key with the middlebox in advance, which in turn implies that the 579 middlebox cannot gain access to the TLS session data. 581 4.2. Encrypted Server Certificate 583 TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and 584 Certificate messages in clear-text. In TLS 1.3, the Certificate 585 message is encrypted whereby hiding the server identity from any 586 intermediary. As a result of this enhancement, it would no longer be 587 possible to observe the server certificate without inspection the 588 encrypted TLS payload. 590 TLS proxies which implement a selective decryption policy will need 591 to alter their behavior to accommodate TLS 1.3. In TLS 1.2 (and 592 earlier), the proxy could observe the TLS handshake till seeing the 593 clear text server certificate to make the decryption policy decision. 594 For example, a proxy may not be permitted to decrypt certain types of 595 traffic such as those going to a banking and health care service. 596 However, in TLS 1.3, the TLS proxy must participate in both 597 handshakes (i.e., client-to-proxy; and proxy-to-server) in order to 598 view the server certificate. This change will impose a slight 599 increase in load per connection on the proxy. 601 5. Security Considerations 603 This entire document discusses security considerations in existing 604 operational security practices interacting with TLS. It notes where 605 existing practices will have to be adjusted to remain effective due 606 to TLS v1.3 improvements. 608 These operational practices involve both good faith and malicious 609 client applications. The former category typically exhibits 610 consistently identifiable behavior and does not actively prevent any 611 transit inspection devices from performing application identification 612 for visibility and control purposes. The latter category of 613 applications actively attempts to circumvent network security 614 controls by deliberately manipulating various protocol headers, 615 injecting specific messages, and varying payload sizes in order to 616 avoid identification or to masquerade as a different permitted 617 application. 619 6. IANA Considerations 621 This document has no IANA actions. 623 7. Appendix A: Summary Impact to Operational Practices with TLS 1.3 625 +---------------------------------------------+-----------------------+ 626 | Operational Practice | Impact with TLS 1.3 | 627 +---------------------------------------------+-----------------------+ 628 | OP-1: AUP enforcement (headers only) | reduced effectiveness | 629 | OP-2: Behavior analytics (headers only) | reduced effectiveness | 630 | OP-3: Crypto compliance monitoring (server) | reduced effectiveness | 631 | OP-4: Crypto compliance monitoring (client) | reduced effectiveness | 632 | OP-5: AUP enforcement (payload) | no capability impact | 633 | OP-6: Data loss prevention compliance | no capability impact | 634 | OP-7: Granular network segmentation | no capability impact | 635 | OP-8: Network protection (client) | no capability impact | 636 | OP-9: Protecting challenging end points | no capability impact | 637 | OP-10: Content Injection | no capability impact | 638 | OP-11: TLS offloading | no impact | 639 | OP-12: Application load balancing | no impact | 640 | OP-13: inline: Network protection (server) | no operational impact | 641 | OP-13: oob: Network protection (server) | alternative required | 642 | OP-14: inline: Full packet capture | no operational impact | 643 | OP-14: oob: Full packet capture | alternative required | 644 | OP-15: Application layer gateway | no impact | 645 +---------------------------------------------+-----------------------+ 647 8. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 655 (TLS) Protocol Version 1.2", RFC 5246, 656 DOI 10.17487/RFC5246, August 2008, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 664 Pervasive Encryption on Operators", RFC 8404, 665 DOI 10.17487/RFC8404, July 2018, 666 . 668 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 669 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 670 . 672 Acknowledgments 674 The authors thank Andrew Ossipov, Flemming Andreasen and Kirsty Paine 675 for their contributions and valuable feedback. 677 Authors' Addresses 679 Nancy Cam-Winget 680 Cisco Systems, Inc. 681 3550 Cisco Way 682 San Jose, CA 95134 683 USA 685 EMail: ncamwing@cisco.com 687 Eric Wang 688 Cisco Systems, Inc. 689 3550 Cisco Way 690 San Jose, CA 95134 691 USA 693 EMail: ejwang@cisco.com 695 Roman Danyliw 696 Software Engineering Institute 698 EMail: rdd@cert.org 700 Roelof DuToit 701 Symantec 703 EMail: r@nerd.ninja