idnits 2.17.1 draft-ietf-opsec-ns-impact-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 65 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 (July 27, 2020) is 1368 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-05 Summary: 2 errors (**), 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: January 28, 2021 R. Danyliw 6 Software Engineering Institute 7 R. DuToit 8 Broadcom 9 July 27, 2020 11 Impact of TLS 1.3 to Operational Network Security Practices 12 draft-ietf-opsec-ns-impact-01 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 January 28, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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). . . . . . . . . . . . . . . . . . 6 64 3.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 6 65 3.1.3. OP-3. Crypto, Security and Security Policy 66 Compliance (server) . . . . . . . . . . . . . . . . . 7 67 3.1.4. OP-4. Crypto and Security Policy Compliance (client) 7 68 3.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 8 69 3.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via 70 payload inspection) . . . . . . . . . . . . . . . . . 9 71 3.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 9 72 3.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 9 73 3.2.4. OP-8: Network-based Threat Protection (client) . . . 9 74 3.2.5. OP-9: Protecting Challenging End Points . . . . . . . 10 75 3.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 10 76 3.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 10 77 3.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 11 78 3.3.2. OP-12. Content distribution and application load 79 balancing . . . . . . . . . . . . . . . . . . . . . . 12 80 3.3.3. OP-13: Network-based Threat Protection (server) . . . 12 81 3.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 12 82 3.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 13 83 4. Changes in TLS v1.3 Relevant to Security Operations . . . . . 13 84 4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 13 85 4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 13 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 7. Appendix A: Summary Impact to Operational Practices with TLS 89 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 8.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Enterprises, public sector organizations, internet service providers 99 and cloud service providers defend their networks and information 100 systems from attacks that originate from inside and outside their 101 networks. These organizations commonly employ security architectures 102 that involve complementary technologies deployed on both endpoints 103 and in the network; and collaborative watch-and-warning practices to 104 realize this defense. 106 The design of these security architectures and associated practices 107 entails numerous trade-offs. Typically, there is more than one 108 technical approach to realize a particular mitigation, although 109 comparable approaches may have different costs or side-effects. 110 Network-based solutions are often attractive to network 111 administrators because a single network device can: 113 o provide protection to many hosts and systems at once 115 o protect systems regardless of their type (e.g., fully patched 116 desktop systems on a modern operating system; unpatched function- 117 specific industrial control system) 119 o enforce policy on a system even if it is compromised, 120 misconfigured, not under configuration control or had its endpoint 121 protection disabled 123 o be managed (e.g. updates) and provisioned with resources (e.g. 124 disk and computing) independent of the systems it is protecting 126 o by itself, a single system may not be able to detect and mitigate 127 threats 129 In response to the adoption of new technologies, protocols and 130 threats, these security architectures must evolve to remain 131 effective. [RFC8404] documented a need to evolve with the effect of 132 pervasive encryption on operations. This document takes a narrower 133 focus by documenting the interaction of existing network-based 134 security practices with TLS v1.2 [RFC5246] (and earlier) traffic to 135 implement security policy, detection or mitigation of threats; and 136 the impact on these practices with improvements made in TLS v1.3 137 [RFC8446]. 139 2. Conventions and Definitions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Specific operational practices are numbered as "OP-##", operational 148 practice 1 (i.e., OP-1), 2 (i.e., OP-2), etc. 150 3. How TLS is used to enable Network-Based Security Solutions 152 Network-based security solutions come in many forms, most commonly as 153 Firewalls, Web Proxies, Intrusion Detection Systems (IDS), Intrusion 154 Prevention Systems (IPS) and Network Security Visibility and 155 Analytics systems. They inspect the network traffic, and then based 156 on their function, log their observation and/or act on the traffic to 157 implement security policy. When these devices act on the network 158 traffic, they are typically deployed inline as middleboxes (e.g. 159 firewalls) or as explicit proxies (e.g. web proxies). If their 160 function is only to observe, they can be deployed either as 161 middleboxes or given access to the network traffic out-of-band (OOB), 162 through the network fabric (e.g., network tap or span port). 164 Depending on their function, network-based security devices use 165 different degrees of visibility into the TLS traffic. Some 166 operational practices require only access to the unencrypted protocol 167 headers and associated meta-data of the TLS traffic. Other practices 168 require full visibility into the encrypted session (payload). 170 The practices that inspect only the unencrypted headers and meta-data 171 of TLS, require no special capabilities beyond access to the TLS 172 packets. However, to inspect the encrypted payload of TLS traffic 173 requires a TLS proxy. 175 A TLS proxy provides visibility and inspection to effectuate security 176 controls without changing the state machine of the TLS Server and TLS 177 Client, or the user experience. The TLS Proxy operates as a 178 transparent hop at the TLS layer in both middlebox and explicit proxy 179 deployments. For the web proxy case, after the client sends an HTTP 180 CONNECT to request a tunnel to the server, the web proxy may insert a 181 TLS Proxy function to proxy the TLS session without awareness by the 182 client or server. The TLS operation afterwards remains the same as a 183 middlebox. 185 To proxy a TLS session, a TLS Proxy must be able to present a valid 186 X.509 certificate to the TLS client to appear as a valid TLS Server; 187 similarly, the client must be able to validate the X.509 certificate 188 using the appropriate trust anchor for that TLS connection. To 189 achieve this, a deployment must properly provision their systems (TLS 190 Proxies and TLS clients). 192 Specific network security operational practices applied to TLS v1.2 193 (and earlier) are described in subsequent sub-sections. They are 194 categorized into the following deployment scenarios: 196 1. Passive TLS inspection, where the network-based security function 197 is inspecting either the inbound or outbound TLS header or meta- 198 data traffic 200 2. Outbound TLS Proxy, where a TLS proxy mediates a TLS session 201 originating from a client inside the enterprise administrative 202 domain (and in the same administrative domain as the proxy) 203 towards an entity on the outside 205 3. Inbound TLS Proxy, where a TLS proxy mediates a TLS session from 206 a client outside the enterprise administrative domain towards an 207 entity on the inside (and in the same administrative domain as 208 the proxy) 210 Each deployment scenario describes current operational practices. 211 For each operational practice, possible deployment modes (e.g., 212 inline, out-of-band), a description of the practice, and the impact 213 of TLS v1.3 is categorized and explained. The categorized impacts to 214 practices when migrating to TLS v1.3 are as follows: 216 o no impact - no change in capability or performance is expected 217 with this practice 219 o no capability impact - no change in capability is expected; but 220 there may be a performance or implementation change required for 221 this practice 223 o reduced effectiveness - this practice will not be as effective on 224 TLS v1.3 traffic 226 o alternative approach required - this practice will not work with 227 TLS v1.3 traffic 229 3.1. Passive TLS Inspection 231 Passive TLS inspection is the deployment scenario where a network 232 security device passively inspects inbound or outbound TLS traffic to 233 make visibility inferences or take policy actions. The network 234 security device examines only the unencrypted TLS protocol headers 235 and does not have access to the encrypted content of the payload. 237 The TLS proxy deployment scenarios may also incorporate these 238 practices. 240 3.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via header 241 inspection). 243 Deployment mode: inline 245 A firewall or web proxy restricts a client in the same administrative 246 domain from accessing sites or services outside that domain per an 247 acceptable use policy. The identification of the destination server 248 is performed through the inspection of either the SNI field in the 249 TLS ClientHello message from the client; or by extracting the server 250 identity from the Common Name (CN) or Subject Alternative Name (SAN) 251 fields of an X.509 certificate that is presented in the server's 252 Certificate TLS message. This data is used for domain categorization 253 or application identification. 255 This meta-data can also inform decryption eligibility decisions by a 256 firewall, in OP-4. For instance, a firewall may bypass traffic 257 decryption for a connection destined to a healthcare web service due 258 to privacy compliance requirements. 260 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, 261 domain categorization and application identification will be limited 262 to IP address and SNI information (beyond additional correlation 263 possible with other means such as DNS). 265 While an SNI is mandatory in TLS 1.3, there is no guarantee that the 266 server responding is the one indicated in the SNI from the client. A 267 SNI alone, without comparison of the server certificate, does not 268 provide reliable information about the server that the client is 269 attempting to reach. Where a client has been compromised by malware, 270 it may present an innocuous SNI to bypass protective filters (e.g., 271 to reach a command and control server), and this will be undetectable 272 under TLS 1.3. 274 [ESNI] will further reduce the effectiveness of passive TLS 275 inspection, limiting the available information to IP addresses and 276 possible correlation with DNS. 278 3.1.2. OP-2. Network Behavior Analytics 280 Deployment mode: inline and out-of-band 282 Network behavior analysis and machine learning engines in IDSs, IPSs 283 and firewalls observe the cleartext fields of the TLS handshake 284 (e.g., session cipher suites) and conducts traffic analysis by 285 observing encrypted record sizes, packet rates and their inter- 286 arrival times, and similar outer connection behavior. They match 287 encrypted connections against known application patterns; identify 288 anomalies; and identify or block those without payload inspection. 289 These analytics may also observe that malicious applications may 290 deliberately manipulate certain TLS header fields, throttle packet 291 rates, and vary payload sizes in order to circumvent detection. 293 Through traffic analysis, researchers have detected devastating 294 pseudo-random number generator failures [TLS_VULNERABILITY], nonce 295 failures [NONCE_FAIL], and deeply flawed random number generators in 296 products in [WEAK_KEY] and [WEAK_K2]. 298 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, any 299 features relying on Certificate information will not be available. 301 3.1.3. OP-3. Crypto, Security and Security Policy Compliance (server) 303 Deployment: out-of-band 305 A network security device observes TLS handshake traffic to audit 306 that TLS server configuration conforms to policy. This compliance 307 monitoring commonly examines ciphersuites (e.g., use of weak 308 ciphersuites) and certificate properties (e.g., no self-signed 309 certificates, black or white list of certificate authorities, 310 certificate expiration times). 312 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only 313 TLS ClientHello and ServerHello parameters can be audited. 314 Certification information will not be visible. 316 3.1.4. OP-4. Crypto and Security Policy Compliance (client) 318 Deployment: inline 320 A network security device observes TLS handshake traffic to ensure 321 that clients negotiating TLS connections have configurations (e.g., 322 only make connections with TLS 1.2+) and server certificate (e.g., 323 black-listed CAs) that adhere to policy. This is a variant of OP-3. 324 It is commonly used in deployments where an organization may have 325 reduced configuration control of end points (e.g., lab environments, 326 Bring Your Own Device arrangements, and IoT). 328 TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only 329 TLS ClientHello and ServerHello parameters can be audited. 330 Certification information will not be visible. 332 3.2. Outbound TLS Proxy 334 Outbound TLS proxy is the deployment scenario where a security device 335 that performs the TLS proxy function is in the same administrative 336 domain as the TLS client, and the TLS server is located in an 337 external zone such as the Internet or in another policy zone of the 338 same administrative domain. Usually the goal is to protect the 339 client endpoint and the organization by controlling application 340 behaviors and enforcing an acceptable use policy for the 341 organizational network. See Figure 1. 343 The administrator manages the TLS client to allow interception by the 344 TLS proxy, usually by deploying a local Certificate Authority (CA) 345 certificate on the TLS client. A typical scenario is an 346 organization-managed client endpoint, such as a laptop or a mobile 347 device that accesses the Internet through the organizational network. 348 When a client attempts to access an external TLS server, the TLS 349 proxy function typically presents a locally signed certificate from 350 the local CA on behalf of the server; alternatively, the certificate 351 generation function may be offloaded to an external Hardware Security 352 Module (HSM) service with which that the TLS proxy must integrate. 354 It has to be noted that the method does not work if the TLS client 355 does not support customized list of CAs, such as with certificate 356 pinning. The impact is independent of TLS 1.3 deployment. 358 _________ __________ 359 \ / 360 \ | Administrative 361 \ | Domain, _----__ 362 +-+ \ | Zone 2 / / \____ 363 | | \ \______/ __/ +------+ \ 364 |C|.. | . / |S-NEWS| \__ 365 | | . | . ( +------+ \ 366 +-+ . +---+ . ( +--------+ ) 367 ..| |.... \ |S-GAMING| ) 368 | P |..........( +--------+ ) 369 +-+ ...| | \ +---------+ ) 370 | | . +---+ ( |S-BANKING| / 371 |C|... | \_.+---------+ ) 372 | | | \.. / 373 +-+ / \____--' 374 / 375 Administrative / Internet 376 Domain, Zone 1 / 377 _________/ 379 Figure 1: Outbound TLS proxy 381 3.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via payload 382 inspection) 384 Deployment: inline 386 A firewall or web proxy restricts a client in the same administrative 387 domain from accessing sites or services outside that domain per an 388 acceptable use policy. Similar in intent to OP-1, but the policy 389 enforcement in this practice requires access to data in the TLS 390 session (e.g., URL). 392 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 393 selective decryption policy is used. 395 3.2.2. OP-6: Data Loss Prevention Compliance 397 Deployment: inline 399 A firewall enforces a Data Loss Prevention (DLP) policy by monitoring 400 the TLS sessions content of outbound communication for systems 401 sending organizational proprietary content or other restricted 402 information. Note that the firewall may be implemented and enforced 403 either at the endpoint or by the network infrastructure. 405 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 406 selective decryption policy is used. 408 3.2.3. OP-7: Granular Network Segmentation 410 Deployment: inline 412 A firewall mediates the traffic between different policy zones in an 413 organization. The access policies between these zones may be based 414 on application names and categories rather than static IP addresses 415 and TCP/UDP port numbers. Through a TLS proxy, the firewall can 416 inspect URLs and other application parameters based on data in the 417 TLS session. 419 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 420 selective decryption policy is used. 422 3.2.4. OP-8: Network-based Threat Protection (client) 424 Deployment: inline or out-of-band (depending on functionality) 426 Web proxies and firewalls protect end-users against a range of 427 threats by inspecting the data in the TLS session with a variety of 428 analytical techniques (e.g., signatures, heuristics, statistical 429 models, machine learning). This practice is a superset of OP-2. 430 Common goals are to prevent malware from reaching the endpoint, 431 preventing malware communication from a compromised host, restricting 432 lateral network movement of an intruder and gathering insight into 433 the behavior of threat activity on the network. 435 In certain deployments these technologies are also used to act as a 436 last line of defense against software vulnerabilities on endpoints - 437 either for 0-days for which there is no patch, or simply unpatched 438 clients. 440 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 441 selective decryption policy is used. 443 3.2.5. OP-9: Protecting Challenging End Points 445 Deployment mode: inline 447 Web proxies, IPS and firewalls implement security policy and afford 448 protection to devices for which it is not feasible to run an end- 449 point solution (e.g., IoT); or that are end-of-life and will not 450 receive patches. This is a specialized instance of OP-8 targeting 451 these disadvantaged classes of devices. 453 These practices ensure that that older endpoints (and in some cases 454 even new ones) are not permanently vulnerable to newly discovered 455 vulnerabilities. 457 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 458 selective decryption policy is used. 460 3.2.6. OP-10: Content Injection 462 Deployment: inline 464 A firewall or web proxy restricts message manipulation or insertion, 465 such as a block page or an interactive authentication portal 466 redirect, into the encrypted flow for the client to see. This may be 467 used in conjunction with OP-1, OP-5, and OP-7. 469 TLS 1.3 considerations: no capability impact. See Section 4.2 if a 470 selective decryption policy is used. 472 3.3. Inbound TLS Proxy 474 Inbound TLS proxy is the deployment scenario where the TLS proxy is 475 deployed in front of one or a set of servers or services. The 476 network device that implements the TLS proxy function is located in 477 the same administrative domain as the server(s) or service(s) it is 478 protecting. Usually it is not predictable or controllable as to 479 which TLS client will initiate a connection. See Figure 2. 481 The TLS proxy is provisioned with the server's certificates and 482 private keys so that it may either decrypt or terminate the TLS 483 connection on behalf of the server. In some instances, the TLS proxy 484 may periodically retrieve the private keys and associated 485 certificates from an external secure distribution service, such as a 486 HSM. Traffic between the TLS proxy and server may be encrypted or in 487 the clear; the former configuration is typical of a perimeter 488 firewall while the latter of a load-balancer. 490 ____________ 491 / 492 / S 493 _----__ / .--. 494 / \____ / |==| 495 __/ / |--| 496 / +-+ +-+ \__ | .....|==| S 497 ( | | | | \ | . |--| .--. 498 ( |C| +-+ |C| +-+ ) +---+ . |::| |==| 499 \ | | | | | | | | ) | |... |__| |--| 500 ( +-+ |C| +-+ |C|..............| P | S " " |==| 501 \ | | | | ) | |... .--. |--| 502 ( +-+ +-+ / +---+ . |==| |::| 503 \_. ) | . |--| |__| 504 \.. / | ..|==| " " 505 \____--' \ |--| 506 \ |::| Administrative 507 External Network \ |__| Domain 508 \ " " 509 \____________ 511 Figure 2: Inbound TLS proxy 513 3.3.1. OP-11: TLS offloading 515 Deployment mode: inline 517 Offloads crypto operations from the application server to a TLS 518 Proxy. This is not a typical security function on its own, but it 519 facilitates security control insertion downstream. As this is in the 520 same administrative domain, it is presumed that a TLS Proxy can be 521 provisioned with the appropriate keys when the TLS Server is 522 configured or managed. 524 TLS 1.3 considerations: no impact. 526 3.3.2. OP-12. Content distribution and application load balancing 528 Deployment mode: inline 530 Load balancers deployed in front of services provide resiliency 531 against denial of service attacks. TLS proxy functionality provides 532 access to the cleartext application layer data to enable service- 533 tailored load balancing. Similar to OP-11, it is presumed that a TLS 534 Proxy can be provisioned with the appropriate keys when the TLS 535 Server is configured or managed. 537 This practice may be combined with OP-11. 539 TLS 1.3 considerations: no impact. 541 3.3.3. OP-13: Network-based Threat Protection (server) 543 Deployment mode: inline and out-of-band 545 Web application firewalls (WAF) and firewalls protect servers and 546 services against a range of threats by inspecting the data in the TLS 547 session with a variety of analytical techniques (e.g., signatures, 548 heuristics, statistical models, machine learning). This practice is 549 identical in function to OP-8, but focused on threat prevention of 550 inbound requests to servers and services. 552 TLS 1.3 considerations for inline deployment mode: no capability 553 impact. Per Section 4.1, the network security device must explicitly 554 terminate the TLS connection from the client. 556 TLS 1.3 considerations for out-of-band mode: alternative approach 557 required. Per Section 4.1, active participation in the TLS exchange 558 is required to inspect the session. 560 3.3.4. OP-14: Full Packet Capture 562 Deployment mode: inline and out-of-band 564 A network security device stores a copy of all decrypted traffic that 565 meets a given filter. This traffic may be continuously captured in a 566 rolling buffer for use in future forensic analysis, incident 567 response, or computationally intensive retrospective analysis. This 568 collection may also be selectively enabled to support application 569 troubleshooting. 571 TLS 1.3 considerations for inline deployment mode: no capability 572 impact. Per Section 4.1, the network security device must explicitly 573 terminate the TLS connection from the client. 575 TLS 1.3 considerations for out-of-band mode: alternative approach 576 required. Per Section 4.1, offline decryption is not possible. 578 3.3.5. OP-15: Application Layer Gateway (ALG) 580 Deployment mode: inline 582 To conduct protocol conformance checks and rewrite embedded IP 583 addresses and TCP/UDP ports within the application layer payload for 584 traffic traversing a NAT boundary. While not strictly a security 585 function, this capability may typically be found in firewalls along 586 with the NAT supporting functions. 588 TLS 1.3 considerations: no impact. 590 4. Changes in TLS v1.3 Relevant to Security Operations 592 TLS v1.3 introduces a number of protocol design changes to improve 593 security and privacy. However, these enhancements impact current 594 network security operational practices that rely on the protocol 595 behavior of earlier TLS versions. 597 4.1. Perfect Forward Secrecy (PFS) 599 TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman 600 (DH) cipher suites, which enables the server's private key to be 601 shared with a TLS proxy. [RFC7525] initiated the recommendation of 602 using AEAD cipher suites and specifically decoupling the cipher suite 603 negotiation based on the RSA key transport; this followed with TLS 604 1.3 explicitly removing support for these cipher suites in favor of 605 supporting only ephemeral mode Diffie-Hellman to provide perfect 606 forward secrecy (PFS). As a result of this enhancement, it would no 607 longer be possible for a server to share a key with the middlebox in 608 advance, which in turn implies that the middlebox cannot gain access 609 to the TLS session data.ss 611 4.2. Encrypted Server Certificate 613 TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and 614 Certificate messages in clear-text. In TLS 1.3, the Certificate 615 message is encrypted whereby hiding the server identity from any 616 intermediary. As a result of this enhancement, it would no longer be 617 possible to observe the server certificate without inspection the 618 encrypted TLS payload. 620 TLS proxies which implement a selective decryption policy will need 621 to alter their behavior to accommodate TLS 1.3. In TLS 1.2 (and 622 earlier), the proxy could observe the TLS handshake till seeing the 623 clear text server certificate to make the decryption policy decision. 624 For example, a proxy may not be permitted to decrypt certain types of 625 traffic such as those going to a banking and health care service. 626 However, in TLS 1.3, the TLS proxy must participate in both 627 handshakes (i.e., client-to-proxy; and proxy-to-server) in order to 628 view the server certificate. This change will impose a slight 629 increase in load per connection on the proxy. 631 5. Security Considerations 633 This document presents common and existing security monitoring and 634 detection functionality and how it interacts with TLS. It further 635 notes where existing practices will have to be adjusted to remain 636 effective as these solutions transition to include TLS v1.3 637 improvements. 639 These operational practices involve both good faith and malicious 640 client applications. The former category typically exhibits 641 consistently identifiable behavior and does not actively prevent any 642 transit inspection devices from performing application identification 643 for visibility and control purposes. The latter category of 644 applications actively attempts to circumvent network security 645 controls by deliberately manipulating various protocol headers, 646 injecting specific messages, and varying payload sizes in order to 647 avoid identification or to masquerade as a different permitted 648 application. 650 6. IANA Considerations 652 This document has no IANA actions. 654 7. Appendix A: Summary Impact to Operational Practices with TLS 1.3 655 +---------------------------------------------+-----------------------+ 656 | Operational Practice | Impact with TLS 1.3 | 657 +---------------------------------------------+-----------------------+ 658 | OP-1: AUP enforcement (headers only) | reduced effectiveness | 659 | OP-2: Behavior analytics (headers only) | reduced effectiveness | 660 | OP-3: Crypto compliance monitoring (server) | reduced effectiveness | 661 | OP-4: Crypto compliance monitoring (client) | reduced effectiveness | 662 | OP-5: AUP enforcement (payload) | no capability impact | 663 | OP-6: Data loss prevention compliance | no capability impact | 664 | OP-7: Granular network segmentation | no capability impact | 665 | OP-8: Network protection (client) | no capability impact | 666 | OP-9: Protecting challenging end points | no capability impact | 667 | OP-10: Content Injection | no capability impact | 668 | OP-11: TLS offloading | no impact | 669 | OP-12: Application load balancing | no impact | 670 | OP-13: inline: Network protection (server) | no operational impact | 671 | OP-13: oob: Network protection (server) | alternative required | 672 | OP-14: inline: Full packet capture | no operational impact | 673 | OP-14: oob: Full packet capture | alternative required | 674 | OP-15: Application layer gateway | no impact | 675 +---------------------------------------------+-----------------------+ 677 8. References 679 8.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 687 (TLS) Protocol Version 1.2", RFC 5246, 688 DOI 10.17487/RFC5246, August 2008, 689 . 691 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 692 "Recommendations for Secure Use of Transport Layer 693 Security (TLS) and Datagram Transport Layer Security 694 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 695 2015, . 697 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 698 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 699 May 2017, . 701 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 702 Pervasive Encryption on Operators", RFC 8404, 703 DOI 10.17487/RFC8404, July 2018, 704 . 706 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 707 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 708 . 710 8.2. Informative References 712 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 713 "Encrypted Server Name Indication for TLS 1.3", draft- 714 ietf-tls-esni-05 (work in progress), November 2019. 716 [NONCE_FAIL] 717 Jovanovic, P., "Nonce-disrespecting adversaries: Practical 718 forgery attacks on GCM in TLS", 2016, 719 . 722 [TLS_VULNERABILITY] 723 Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in 724 the Wild", 2017, 725 . 727 [WEAK_K2] Heninger, N., "Weak Keys Remain Widespread in Network 728 Devices", 2016, . 731 [WEAK_KEY] 732 Halderman, A., "Mining your Ps and Qs: Detection of 733 widespread weak keys in network devices", 2012, 734 . 737 Acknowledgments 739 The authors thank Andrew Ossipov, Flemming Andreasen, Kirsty Paine, 740 David McGrew, and Eric Vyncke for their contributions and valuable 741 feedback. 743 Authors' Addresses 745 Nancy Cam-Winget 746 Cisco Systems, Inc. 747 3550 Cisco Way 748 San Jose, CA 95134 749 USA 751 EMail: ncamwing@cisco.com 753 Eric Wang 754 Cisco Systems, Inc. 755 3550 Cisco Way 756 San Jose, CA 95134 757 USA 759 EMail: ejwang@cisco.com 761 Roman Danyliw 762 Software Engineering Institute 764 EMail: rdd@cert.org 766 Roelof DuToit 767 Broadcom 769 EMail: roelof.dutoit@broadcom.com