idnits 2.17.00 (12 Aug 2021) /tmp/idnits29512/draft-ietf-opsec-ns-impact-04.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 == Line 69 has weird spacing: '...ecurity and S...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 26, 2021) is 473 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 (-14) exists of draft-ietf-tls-esni-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC Working Group N. Cam-Winget 3 Internet-Draft E. Wang 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: July 30, 2021 R. Danyliw 6 Software Engineering Institute 7 R. DuToit 8 Broadcom 9 January 26, 2021 11 Impact of TLS 1.3 to Operational Network Security Practices 12 draft-ietf-opsec-ns-impact-04 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 TLS is 19 a widely deployed protocol to secure communication, these network- 20 based security solutions must necessarily interact with it. 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 July 30, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . 4 60 3. How TLS is used to enable Network-Based Security Solutions . 4 61 4. Changes in TLS 1.3 Relevant to Security Operations . . . . . 5 62 4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 5 63 4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 5 64 5. Network Security Operational Practices . . . . . . . . . . . 6 65 5.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 7 66 5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via 67 header inspection). . . . . . . . . . . . . . . . . . 7 68 5.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 8 69 5.1.3. OP-3. Crypto, Security and Security Policy 70 Compliance (server) . . . . . . . . . . . . . . . . . 8 71 5.1.4. OP-4. Crypto and Security Policy Compliance (client) 8 72 5.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 9 73 5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via 74 payload inspection) . . . . . . . . . . . . . . . . . 10 75 5.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 10 76 5.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 11 77 5.2.4. OP-8: Network-based Threat Protection (client) . . . 11 78 5.2.5. OP-9: Protecting Challenging End Points . . . . . . . 11 79 5.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 12 80 5.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 12 81 5.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 13 82 5.3.2. OP-12. Content distribution and application load 83 balancing . . . . . . . . . . . . . . . . . . . . . . 13 84 5.3.3. OP-13: Network-based Threat Protection (server) . . . 14 85 5.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 14 86 5.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 14 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 8. Appendix A: Summary Impact to Operational Practices with TLS 90 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 9.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 Enterprises, public sector organizations, internet service providers 100 and cloud service providers defend their networks and information 101 systems from attacks that originate from inside and outside their 102 networks. These organizations commonly employ security architectures 103 that involve complementary technologies deployed on both endpoints 104 and in the network; and collaborative watch-and-warning practices to 105 realize this defense. 107 The design of these security architectures and associated practices 108 entails numerous trade-offs. Typically, there is more than one 109 technical approach to realize a particular mitigation, although 110 comparable approaches may have different costs or side-effects. 111 Network-based solutions are often attractive to network 112 administrators because a single network device can: 114 o provide protection to many hosts and systems at once 116 o protect systems regardless of their type (e.g., fully patched 117 desktop systems on a modern operating system; unpatched function- 118 specific industrial control system) 120 o enforce policy on a system even if it is compromised, 121 misconfigured, not under configuration control or had its endpoint 122 protection disabled 124 o be managed (e.g. updates) and provisioned with resources (e.g. 125 disk and computing) independent of the systems it is protecting 127 o by itself, a single system may not be able to detect and mitigate 128 threats 130 Security architectures must evolve in response to the adoption of new 131 technologies, protocols and threats to remain effective. [RFC8404] 132 documented such an evolution in the context of the adoption of 133 pervasive encryption. Taking a narrowing focus, this document 134 enumerates existing network-based security practices that enforce 135 policy on; or are used to detect or mitigate threats in TLS 1.2 136 [RFC5246] (and earlier) traffic. This document is not a complete 137 survey of these practices or a comprehensive migration guide to TLS 138 1.3. 140 In response to pervasive monitoring practices [RFC7258], TLS 1.3 141 [RFC8446] explicitly engineered for improved security and privacy 142 properties (see Section 4). In order to aid operators with adoption, 143 this document describes the impact of TLS 1.3 on these existing 144 network security practices and highlights areas where security 145 architectures will require evolution. 147 The document is not intended to endorse the use of TLS inspection. 149 2. Conventions and Definitions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 Specific operational practices are numbered as "OP-##", operational 158 practice 1 (i.e., OP-1), 2 (i.e., OP-2), etc. 160 3. How TLS is used to enable Network-Based Security Solutions 162 Network-based security solutions come in many forms, most commonly as 163 Firewalls, Web Proxies, Intrusion Detection Systems (IDS), Intrusion 164 Prevention Systems (IPS) and Network Security Visibility and 165 Analytics systems. They inspect the network traffic, and then based 166 on their function, log their observation and/or act on the traffic to 167 implement security policy. The conditions under which TLS visibility 168 is required is specific to the network security vendor and deployment 169 and out of scope for this document but the use of visibility and 170 inspection are common and described herein. When these devices act 171 on the network traffic, they are typically deployed inline as 172 middleboxes (e.g. firewalls) or as explicit proxies (e.g. web 173 proxies). 174 If their function is only to observe, they can be deployed either as 175 middleboxes or given access to the network traffic out-of-band (OOB), 176 through the network fabric (e.g., network tap or span port). 178 Depending on their function, network-based security devices use 179 different degrees of visibility into the TLS traffic. Some 180 operational practices require only access to the unencrypted protocol 181 headers and associated meta-data of the TLS traffic. Other practices 182 require full visibility into the encrypted session (payload). 184 The practices that inspect only the unencrypted headers and meta-data 185 of TLS, require no special capabilities beyond access to the TLS 186 packets. However, to inspect the encrypted payload of TLS traffic 187 requires a TLS proxy. 189 A TLS proxy provides visibility and inspection to effectuate security 190 controls without changing the state machine of the TLS Server and TLS 191 Client, or the user experience. The TLS Proxy operates as a 192 transparent hop at the TLS layer in both middlebox and explicit proxy 193 deployments. For the web proxy case, after the client sends an HTTP 194 CONNECT to request a tunnel to the server, the web proxy may insert a 195 TLS Proxy function to proxy the TLS session without awareness by the 196 client or server. The TLS operation afterwards remains the same as a 197 middlebox. 199 To proxy a TLS session, a TLS Proxy must be able to present a valid 200 X.509 certificate to the TLS client to appear as a valid TLS Server; 201 similarly, the client must be able to validate the X.509 certificate 202 using the appropriate trust anchor for that TLS connection. To 203 achieve this, a deployment must properly provision their systems (TLS 204 Proxies and TLS clients). A TLS Proxy is unable to proxy a PSK based 205 session unless it is on-path and has proxied the session leading to 206 the PSK. TLS client authentication requires additional provisioning 207 for X.509 certificate on the TLS Server side. It does not have 208 impact on the deployment scenarios though. 210 4. Changes in TLS 1.3 Relevant to Security Operations 212 TLS 1.3 introduces a number of protocol design changes to improve 213 security and privacy. However, these enhancements impact current 214 network security operational practices that rely on the protocol 215 behavior of earlier TLS versions. 217 4.1. Perfect Forward Secrecy (PFS) 219 TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman 220 (DH) cipher suites, which enables the server's private key to be 221 shared with a TLS proxy. [RFC7525] initiated the recommendation of 222 using AEAD cipher suites and specifically decoupling the cipher suite 223 negotiation based on the RSA key transport; this followed with TLS 224 1.3 explicitly removing support for these cipher suites in favor of 225 supporting only ephemeral mode Diffie-Hellman to provide perfect 226 forward secrecy (PFS). As a result of this enhancement, it would no 227 longer be possible for a server to share a key with the middlebox in 228 advance, which in turn implies that the middlebox cannot gain access 229 to the TLS session data. 231 4.2. Encrypted Server Certificate 233 TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and 234 Certificate messages in clear-text. In TLS 1.3, the Certificate 235 message is encrypted whereby hiding the server identity from any 236 intermediary. As a result of this enhancement, it would no longer be 237 possible to observe the server certificate without inspection the 238 encrypted TLS payload. 240 TLS proxies which implement a selective decryption policy will need 241 to alter their behavior to accommodate TLS 1.3. In TLS 1.2 (and 242 earlier), the proxy could observe the TLS handshake till seeing the 243 clear text server certificate to make the decryption policy decision. 244 For example, a proxy may not be permitted to decrypt certain types of 245 traffic such as those going to a banking and health care service. 246 However, in TLS 1.3, the TLS proxy must participate in both 247 handshakes (i.e., client-to-proxy; and proxy-to-server) in order to 248 view the server certificate. This change will impose a slight 249 increase in load per connection on the proxy. 251 5. Network Security Operational Practices 253 Specific network security operational practices applied to TLS 1.2 254 (and earlier) are described in subsequent sub-sections. They are 255 categorized into the following deployment scenarios: 257 1. Passive TLS inspection, where the network-based security function 258 is inspecting either the inbound or outbound TLS header or meta- 259 data traffic 261 2. Outbound TLS Proxy, where a TLS proxy mediates a TLS session 262 originating from a client inside the enterprise administrative 263 domain (and in the same administrative domain as the proxy) 264 towards an entity on the outside 266 3. Inbound TLS Proxy, where a TLS proxy mediates a TLS session from 267 a client outside the enterprise administrative domain towards an 268 entity on the inside (and in the same administrative domain as 269 the proxy) 271 Each deployment scenario describes current operational practices. 272 For each operational practice, possible deployment modes (e.g., 273 inline, out-of-band), a description of the practice, and the impact 274 of TLS 1.3 is categorized and explained. The categorized impacts to 275 practices when migrating to TLS 1.3 are as follows: 277 o no impact - no change in capability or performance is expected 278 with this practice 280 o no capability impact - no change in capability is expected; but 281 there may be a performance or implementation change required for 282 this practice 284 o reduced effectiveness - this practice will not be as effective on 285 TLS 1.3 traffic 287 o alternative approach required - this practice will not work with 288 TLS 1.3 traffic 290 It should be noted that [ECH] will further reduce the effectiveness 291 (passive inspection) or prevent certain practices (outbound proxy) 292 from being deployed. More study is required in this area. 294 5.1. Passive TLS Inspection 296 Passive TLS inspection is the deployment scenario where a network 297 security device passively inspects inbound or outbound TLS traffic to 298 make visibility inferences or take policy actions. The network 299 security device examines only the unencrypted TLS protocol headers 300 and does not have access to the encrypted content of the payload. 302 The TLS proxy deployment scenarios may also incorporate these 303 practices. 305 5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via header 306 inspection). 308 Deployment mode: inline 310 A firewall or web proxy restricts a client in the same administrative 311 domain from accessing sites or services outside that domain per an 312 acceptable use policy. The identification of the destination server 313 is performed through the inspection of either the SNI field in the 314 TLS ClientHello message from the client; or by extracting the server 315 identity from the Common Name (CN) or Subject Alternative Name (SAN) 316 fields of an X.509 certificate that is presented in the server's 317 Certificate TLS message. This data is used for domain categorization 318 or application identification. 320 This meta-data can also inform decryption eligibility decisions by a 321 firewall, in OP-4. For instance, a firewall may bypass traffic 322 decryption for a connection destined to a healthcare web service due 323 to privacy compliance requirements. 325 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, 326 domain categorization and application identification will be limited 327 to IP address and SNI information (beyond additional correlation 328 possible with other means such as DNS). 330 While an SNI is mandatory in TLS 1.3, there is no guarantee that the 331 server responding is the one indicated in the SNI from the client. A 332 SNI alone, without comparison of the server certificate, does not 333 provide reliable information about the server that the client is 334 attempting to reach. Where a client has been compromised by malware, 335 it may present an innocuous SNI to bypass protective filters (e.g., 336 to reach a command and control server), and this will be undetectable 337 under TLS 1.3. 339 5.1.2. OP-2. Network Behavior Analytics 341 Deployment mode: inline and out-of-band 343 Network behavior analysis and machine learning engines in IDSs, IPSs 344 and firewalls observe the cleartext fields of the TLS handshake 345 (e.g., session cipher suites) and conducts traffic analysis by 346 observing encrypted record sizes, packet rates and their inter- 347 arrival times, and similar outer connection behavior. They match 348 encrypted connections against known application patterns; identify 349 anomalies; and identify or block those without payload inspection. 350 These analytics may also observe that malicious applications may 351 deliberately manipulate certain TLS header fields, throttle packet 352 rates, and vary payload sizes in order to circumvent detection. 354 Through traffic analysis, researchers have detected devastating 355 pseudo-random number generator failures [TLS_VULNERABILITY], nonce 356 failures [NONCE_FAIL], and deeply flawed random number generators in 357 products in [WEAK_KEY] and [WEAK_K2]. 359 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, any 360 features relying on Certificate information will not be available. 362 5.1.3. OP-3. Crypto, Security and Security Policy Compliance (server) 364 Deployment: out-of-band 366 A network security device observes TLS handshake traffic to audit 367 that TLS server configuration conforms to policy. This compliance 368 monitoring commonly examines ciphersuites (e.g., use of weak 369 ciphersuites) and certificate properties (e.g., no self-signed 370 certificates, black or white list of certificate authorities, 371 certificate expiration times). 373 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only 374 TLS ClientHello and ServerHello parameters can be audited. 375 Certification information will not be visible. 377 5.1.4. OP-4. Crypto and Security Policy Compliance (client) 379 Deployment: inline 381 A network security device observes TLS handshake traffic to ensure 382 that clients negotiating TLS connections have configurations (e.g., 383 only make connections with TLS 1.2+) and server certificate (e.g., 384 black-listed CAs) that adhere to policy. This is a variant of OP-3. 385 It is commonly used in deployments where an organization may have 386 reduced configuration control of end points (e.g., lab environments, 387 Bring Your Own Device arrangements, and IoT). 389 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only 390 TLS ClientHello and ServerHello parameters can be audited. 391 Certification information will not be visible. 393 5.2. Outbound TLS Proxy 395 Outbound TLS proxy is the deployment scenario where a security device 396 that performs the TLS proxy function is in the same administrative 397 domain as the TLS client, and the TLS server is located in an 398 external zone such as the Internet or in another policy zone of the 399 same administrative domain. Usually the goal is to protect the 400 client endpoint and the organization by controlling application 401 behaviors and enforcing an acceptable use policy for the 402 organizational network. See Figure 1. 404 The administrator manages the TLS client to allow interception by the 405 TLS proxy, usually by deploying a local Certificate Authority (CA) 406 certificate on the TLS client. A typical scenario is an 407 organization-managed client endpoint, such as a laptop or a mobile 408 device that accesses the Internet through the organizational network. 409 When a client attempts to access an external TLS server, the TLS 410 proxy function typically presents a locally signed certificate from 411 the local CA on behalf of the server; alternatively, the certificate 412 generation function may be offloaded to an external Hardware Security 413 Module (HSM) service with which that the TLS proxy must integrate. 415 It has to be noted that the method does not work if the TLS client 416 does not support customized list of CAs, such as with certificate 417 pinning. The impact is independent of TLS 1.3 deployment. 419 _________ __________ 420 \ / 421 \ | Administrative 422 \ | Domain, _----__ 423 +-+ \ | Zone 2 / / \____ 424 | | \ \______/ __/ +------+ \ 425 |C|.. | . / |S-NEWS| \__ 426 | | . | . ( +------+ \ 427 +-+ . +---+ . ( +--------+ ) 428 ..| |.... \ |S-GAMING| ) 429 | P |..........( +--------+ ) 430 +-+ ...| | \ +---------+ ) 431 | | . +---+ ( |S-BANKING| / 432 |C|... | \_.+---------+ ) 433 | | | \.. / 434 +-+ / \____--' 435 / 436 Administrative / Internet 437 Domain, Zone 1 / 438 _________/ 440 Figure 1: Outbound TLS proxy 442 5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via payload 443 inspection) 445 Deployment: inline 447 A firewall or web proxy restricts a client in the same administrative 448 domain from accessing sites or services outside that domain per an 449 acceptable use policy. Similar in intent to OP-1, but the policy 450 enforcement in this practice requires access to data in the TLS 451 session (e.g., URL). 453 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 454 selective decryption policy is used. 456 5.2.2. OP-6: Data Loss Prevention Compliance 458 Deployment: inline 460 A firewall enforces a Data Loss Prevention (DLP) policy by monitoring 461 the TLS sessions content of outbound communication for systems 462 sending organizational proprietary content or other restricted 463 information. Note that the firewall may be implemented and enforced 464 either at the endpoint or by the network infrastructure. 466 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 467 selective decryption policy is used. 469 5.2.3. OP-7: Granular Network Segmentation 471 Deployment: inline 473 A firewall mediates the traffic between different policy zones in an 474 organization. The access policies between these zones may be based 475 on application names and categories rather than static IP addresses 476 and TCP/UDP port numbers. Through a TLS proxy, the firewall can 477 inspect URLs and other application parameters based on data in the 478 TLS session. 480 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 481 selective decryption policy is used. 483 5.2.4. OP-8: Network-based Threat Protection (client) 485 Deployment: inline or out-of-band (depending on functionality) 487 Web proxies and firewalls protect end-users against a range of 488 threats by inspecting the data in the TLS session with a variety of 489 analytical techniques (e.g., signatures, heuristics, statistical 490 models, machine learning). This practice is a superset of OP-2. 491 Common goals are to prevent malware from reaching the endpoint, 492 preventing malware communication from a compromised host, restricting 493 lateral network movement of an intruder and gathering insight into 494 the behavior of threat activity on the network. 496 In certain deployments these technologies are also used to act as a 497 last line of defense against software vulnerabilities on endpoints - 498 either for 0-days for which there is no patch, or simply unpatched 499 clients. 501 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 502 selective decryption policy is used. 504 5.2.5. OP-9: Protecting Challenging End Points 506 Deployment mode: inline 508 Web proxies, IPS and firewalls implement security policy and afford 509 protection to devices for which it is not feasible to run an end- 510 point solution (e.g., IoT); or that are end-of-life and will not 511 receive patches. This is a specialized instance of OP-8 targeting 512 these disadvantaged classes of devices. 514 These practices ensure that that older endpoints (and in some cases 515 even new ones) are not permanently vulnerable to newly discovered 516 vulnerabilities. 518 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 519 selective decryption policy is used. 521 5.2.6. OP-10: Content Injection 523 Deployment: inline 525 A firewall or web proxy restricts message manipulation or insertion, 526 such as a block page or an interactive authentication portal 527 redirect, into the encrypted flow for the client to see. This may be 528 used in conjunction with OP-1, OP-5, and OP-7. 530 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 531 selective decryption policy is used. 533 5.3. Inbound TLS Proxy 535 Inbound TLS proxy is the deployment scenario where the TLS proxy is 536 deployed in front of one or a set of servers or services. The 537 network device that implements the TLS proxy function is located in 538 the same administrative domain as the server(s) or service(s) it is 539 protecting. Usually it is not predictable or controllable as to 540 which TLS client will initiate a connection. See Figure 2. 542 The TLS proxy is provisioned with the server's certificates and 543 private keys so that it may either decrypt or terminate the TLS 544 connection on behalf of the server. In some instances, the TLS proxy 545 may periodically retrieve the private keys and associated 546 certificates from an external secure distribution service, such as a 547 HSM. Traffic between the TLS proxy and server may be encrypted or in 548 the clear; the former configuration is typical of a perimeter 549 firewall while the latter of a load-balancer. 551 ____________ 552 / 553 / S 554 _----__ / .--. 555 / \____ / |==| 556 __/ / |--| 557 / +-+ +-+ \__ | .....|==| S 558 ( | | | | \ | . |--| .--. 559 ( |C| +-+ |C| +-+ ) +---+ . |::| |==| 560 \ | | | | | | | | ) | |... |__| |--| 561 ( +-+ |C| +-+ |C|..............| P | S " " |==| 562 \ | | | | ) | |... .--. |--| 563 ( +-+ +-+ / +---+ . |==| |::| 564 \_. ) | . |--| |__| 565 \.. / | ..|==| " " 566 \____--' \ |--| 567 \ |::| Administrative 568 External Network \ |__| Domain 569 \ " " 570 \____________ 572 Figure 2: Inbound TLS proxy 574 5.3.1. OP-11: TLS offloading 576 Deployment mode: inline 578 Offloads crypto operations from the application server to a TLS 579 Proxy. This is not a typical security function on its own, but it 580 facilitates security control insertion downstream. As this is in the 581 same administrative domain, it is presumed that a TLS Proxy can be 582 provisioned with the appropriate keys when the TLS Server is 583 configured or managed. 585 TLS 1.3 considerations: no impact. 587 5.3.2. OP-12. Content distribution and application load balancing 589 Deployment mode: inline 591 Load balancers deployed in front of services provide resiliency 592 against denial of service attacks. TLS proxy functionality provides 593 access to the cleartext application layer data to enable service- 594 tailored load balancing. Similar to OP-11, it is presumed that a TLS 595 Proxy can be provisioned with the appropriate keys when the TLS 596 Server is configured or managed. 598 This practice may be combined with OP-11. 600 TLS 1.3 considerations: no impact. 602 5.3.3. OP-13: Network-based Threat Protection (server) 604 Deployment mode: inline and out-of-band 606 Web application firewalls (WAF) and firewalls protect servers and 607 services against a range of threats by inspecting the data in the TLS 608 session with a variety of analytical techniques (e.g., signatures, 609 heuristics, statistical models, machine learning). This practice is 610 identical in function to OP-8, but focused on threat prevention of 611 inbound requests to servers and services. 613 TLS 1.3 considerations for inline deployment mode: no capability 614 impact. Per Section 4.1, the network security device must explicitly 615 terminate the TLS connection from the client. 617 TLS 1.3 considerations for out-of-band mode: alternative approach 618 required. Per Section 4.1, active participation in the TLS exchange 619 is required to inspect the session. 621 5.3.4. OP-14: Full Packet Capture 623 Deployment mode: inline and out-of-band 625 A network security device stores a copy of all decrypted traffic that 626 meets a given filter. This traffic may be continuously captured in a 627 rolling buffer for use in future forensic analysis, incident 628 response, or computationally intensive retrospective analysis. This 629 collection may also be selectively enabled to support application 630 troubleshooting. 632 TLS 1.3 considerations for inline deployment mode: no capability 633 impact. Per Section 4.1, the network security device must explicitly 634 terminate the TLS connection from the client. 636 TLS 1.3 considerations for out-of-band mode: alternative approach 637 required. Per Section 4.1, offline decryption is not possible. 639 5.3.5. OP-15: Application Layer Gateway (ALG) 641 Deployment mode: inline 643 To conduct protocol conformance checks and rewrite embedded IP 644 addresses and TCP/UDP ports within the application layer payload for 645 traffic traversing a NAT boundary. While not strictly a security 646 function, this capability may typically be found in firewalls along 647 with the NAT supporting functions. 649 TLS 1.3 considerations: no impact. 651 6. Security Considerations 653 This document presents common and existing security monitoring and 654 detection functionality and how it interacts with TLS. It further 655 notes where existing practices will have to evolve as TLS 1.3 is 656 adopted. 658 These operational practices involve both good faith and malicious 659 client applications. The former category typically exhibits 660 consistently identifiable behavior and does not actively prevent any 661 transit inspection devices from performing application identification 662 for visibility and control purposes. The latter category of 663 applications actively attempts to circumvent network security 664 controls by deliberately manipulating various protocol headers, 665 injecting specific messages, and varying payload sizes in order to 666 avoid identification or to masquerade as a different permitted 667 application. 669 7. IANA Considerations 671 This document has no IANA actions. 673 8. Appendix A: Summary Impact to Operational Practices with TLS 1.3 675 +---------------------------------------------+-----------------------+ 676 | Operational Practice | Impact with TLS 1.3 | 677 +---------------------------------------------+-----------------------+ 678 | OP-1: AUP enforcement (headers only) | reduced effectiveness | 679 | OP-2: Behavior analytics (headers only) | reduced effectiveness | 680 | OP-3: Crypto compliance monitoring (server) | reduced effectiveness | 681 | OP-4: Crypto compliance monitoring (client) | reduced effectiveness | 682 | OP-5: AUP enforcement (payload) | no capability impact | 683 | OP-6: Data loss prevention compliance | no capability impact | 684 | OP-7: Granular network segmentation | no capability impact | 685 | OP-8: Network protection (client) | no capability impact | 686 | OP-9: Protecting challenging end points | no capability impact | 687 | OP-10: Content Injection | no capability impact | 688 | OP-11: TLS offloading | no impact | 689 | OP-12: Application load balancing | no impact | 690 | OP-13: inline: Network protection (server) | no operational impact | 691 | OP-13: oob: Network protection (server) | alternative required | 692 | OP-14: inline: Full packet capture | no operational impact | 693 | OP-14: oob: Full packet capture | alternative required | 694 | OP-15: Application layer gateway | no impact | 695 +---------------------------------------------+-----------------------+ 697 9. References 699 9.1. Normative References 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, 703 DOI 10.17487/RFC2119, March 1997, 704 . 706 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 707 (TLS) Protocol Version 1.2", RFC 5246, 708 DOI 10.17487/RFC5246, August 2008, 709 . 711 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 712 "Recommendations for Secure Use of Transport Layer 713 Security (TLS) and Datagram Transport Layer Security 714 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 715 2015, . 717 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 718 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 719 May 2017, . 721 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 722 Pervasive Encryption on Operators", RFC 8404, 723 DOI 10.17487/RFC8404, July 2018, 724 . 726 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 727 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 728 . 730 9.2. Informative References 732 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 733 Encrypted Client Hello", draft-ietf-tls-esni-07 (work in 734 progress), June 2020. 736 [NONCE_FAIL] 737 Jovanovic, P., "Nonce-disrespecting adversaries: Practical 738 forgery attacks on GCM in TLS", 2016, 739 . 742 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 743 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 744 2014, . 746 [TLS_VULNERABILITY] 747 Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in 748 the Wild", 2017, 749 . 751 [WEAK_K2] Heninger, N., "Weak Keys Remain Widespread in Network 752 Devices", 2016, . 755 [WEAK_KEY] 756 Halderman, A., "Mining your Ps and Qs: Detection of 757 widespread weak keys in network devices", 2012, 758 . 761 Acknowledgments 763 The authors thank Andrew Ossipov, Flemming Andreasen, Kirsty Paine, 764 David McGrew, and Eric Vyncke for their contributions and valuable 765 feedback. 767 Authors' Addresses 769 Nancy Cam-Winget 770 Cisco Systems, Inc. 771 3550 Cisco Way 772 San Jose, CA 95134 773 USA 775 EMail: ncamwing@cisco.com 777 Eric Wang 778 Cisco Systems, Inc. 779 3550 Cisco Way 780 San Jose, CA 95134 781 USA 783 EMail: ejwang@cisco.com 785 Roman Danyliw 786 Software Engineering Institute 788 EMail: rdd@cert.org 790 Roelof DuToit 791 Broadcom 793 EMail: roelof.dutoit@broadcom.com