idnits 2.17.1 draft-camwinget-tls-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'BreakTLS' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC7627' is defined on line 664, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-02 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS F. Andreasen 3 Internet-Draft N. Cam-Winget 4 Intended status: Informational E. Wang 5 Expires: September 6, 2018 Cisco Systems 6 March 5, 2018 8 TLS 1.3 Impact on Network-Based Security 9 draft-camwinget-tls-use-cases-01 11 Abstract 13 Network-based security solutions are used by enterprises, public 14 sector, and cloud service providers today in order to both complement 15 and augment host-based security solutions. TLS 1.3 introduces 16 several changes to TLS 1.2 with a goal to improve the overall 17 security and privacy provided by TLS. However some of these changes 18 have a negative impact on network-based security solutions. While 19 this may be viewed as a feature, there are several real-life use case 20 scenarios that are not easily solved without such network-based 21 security solutions. In this document, we identify the TLS 1.3 22 changes that may impact network-based security solutions and provide 23 a set of use case scenarios that are not easily solved without such 24 solutions. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 6, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 62 2. TLS 1.3 Change Impact Overview . . . . . . . . . . . . . . . 5 63 2.1. Inbound Session Change Impacts . . . . . . . . . . . . . 5 64 2.1.1. Removal of Static RSA and Diffie-Hellman Cipher 65 Suites . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Outbound Session Change Impacts . . . . . . . . . . . . . 5 67 2.2.1. Encrypted Server Certificate . . . . . . . . . . . . 5 68 2.2.2. Resumption and Pre-Shared Key . . . . . . . . . . . . 6 69 2.2.3. Version Negotiation and Downgrade Protection . . . . 7 70 2.2.4. SNI Encryption in TLS Through Tunneling . . . . . . . 8 71 3. Inbound Session Use Cases . . . . . . . . . . . . . . . . . . 8 72 3.1. Use Case I1 - Data Center Protection . . . . . . . . . . 8 73 3.2. Use Case I2 - Application Operation over NAT . . . . . . 9 74 3.3. Use Case I3 - Compliance . . . . . . . . . . . . . . . . 9 75 3.4. Use Case I4 - Crypto Security Audit . . . . . . . . . . . 9 76 4. Outbound Session Use Cases . . . . . . . . . . . . . . . . . 10 77 4.1. Use Case O1 - Acceptable Use Policy (AUP) . . . . . . . . 10 78 4.2. Use Case O2 - Malware and Threat Protection . . . . . . . 11 79 4.3. Use Case O3 - IoT Endpoints . . . . . . . . . . . . . . . 11 80 4.4. Use Case O4 - Unpatched Endpoints . . . . . . . . . . . . 11 81 4.5. Use Case O5 - Rapid Containment of New Vulnerability and 82 Campaigns . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.6. Use Case O6 - End-of-Life Endpoint . . . . . . . . . . . 12 84 4.7. Use Case O7 - Compliance . . . . . . . . . . . . . . . . 12 85 4.8. Use Case O8 - Crypto Security Audit . . . . . . . . . . . 13 86 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 13 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 93 9.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 Enterprises, public sector, and cloud service providers need to 99 defend their information systems from attacks originating from both 100 inside and outside their networks. Protection and detection are 101 typically done both on end hosts and in the network. Host agents 102 have deep visibility on the devices where they are installed, whereas 103 the network has broader visibility and provides homogenous security 104 controls across heterogenous endpoints, covering devices for which no 105 host monitoring is available (which is common today and is 106 increasingly so in the Internet of Things). This helps protect 107 against unauthorized devices installed by insiders, and provides a 108 fallback in case the infection of a host disables its security agent. 109 Because of these advantages, network-based security mechanisms are 110 widely used. In fact, regulatory standards such as NERC CIP 111 [NERCCIP] place strong requirements about network perimeter security 112 and its ability to have visibility to provide security information to 113 the security management and control systems. At the same time, the 114 privacy of employees, customers, and other users must be respected by 115 minimizing the collection of personal data and controlling access to 116 what data is collected. These imperatives hold for both end host and 117 network based security monitoring. 119 Network-based security solutions such as Firewalls (FW) and Intrusion 120 Prevention Systems (IPS) rely on network traffic inspection to 121 implement perimeter-based security policies. Depending on the 122 security functions required, these middleboxes can either be deployed 123 as traffic monitoring devices or active in-line devices. A traffic 124 monitoring middlebox may for example perform vulnerability detection, 125 intrusion detection, crypto audit, compliance monitoring, etc. An 126 active in-line middlebox may for example prevent malware download, 127 block known malicious URLs, enforce use of strong ciphers, stop data 128 exfiltration, etc. A significant portion of such security policies 129 require clear-text traffic inspection above Layer 4, which becomes 130 problematic when traffic is encrypted with Transport Layer Security 131 (TLS) [RFC5246]. Today, network-based security solutions typically 132 address this problem by becoming a man-in-the-middle (MITM) for the 133 TLS session according to one of the following two scenarios: 135 1. Outbound Session, where the TLS session originates from a client 136 inside the perimeter towards an entity on the outside 138 2. Inbound Session, where the TLS session originates from a client 139 outside the perimeter towards an entity on the inside 141 For the outbound session scenario, MITM is enabled by generating a 142 local root certificate and an accompanying (local) public/private key 143 pair. The local root certificate is installed on the inside entities 144 for which TLS traffic is to be inspected, and the network security 145 device(s) store a copy of the private key. During the TLS handshake, 146 the network security device (hereafter referred to as a TLS proxy) 147 modifies the certificate provided by the (outside) server and 148 (re)signs it with the private key from the local root certificate. 149 From here on, the TLS proxy has visibility into further exchanges 150 between the client and server which enables it to decrypt and inspect 151 subsequent network traffic. 153 For the inbound session scenario, the TLS proxy is configured with a 154 copy of the local servers' certificate(s) and corresponding private 155 key(s). Based on the server certificate presented, the TLS proxy 156 determines the corresponding private key, which again enables the TLS 157 proxy to gain visibility into further exchanges between the client 158 and server and hence decrypt subsequent network traffic. 160 To date, there are a number of use case scenarios that rely on the 161 above capabilities when used with TLS 1.2 [RFC5246] or earlier. TLS 162 1.3 [I-D.ietf-tls-tls13] introduces several changes which prevent a 163 number of these use case scenarios from being satisfied with the 164 types of TLS proxy based capabilities that exist today. 166 It has been noted, that currently deployed TLS proxies (middleboxes) 167 may reduce the security of the TLS connection itself due to a 168 combination of poor implementation and configuration, and they may 169 compromise privacy when decrypting a TLS session. As such, it has 170 been argued that preventing TLS proxies from working should be viewed 171 as a feature of TLS 1.3 and that the proper way of solving these 172 issues is to rely on endpoint (client and server) based solutions 173 instead. We believe this is an overly constrained view of the 174 problem that ignores a number of important real-life use case 175 scenarios that improve the overall security posture. We also note 176 that current endpoint-based TLS proxies suffer from many of the same 177 security issues as the network-based TLS proxies do [HTTPSintercept]. 179 The purpose of this document is to provide a representative set of 180 _network based security_ use case scenarios that are negatively 181 impacted by TLS 1.3 and do not lend themselves to an endpoint-based 182 alternative solution. For each use case scenario, we highlight the 183 specific aspect(s) of TLS 1.3 that makes the use case problematic 184 with a TLS proxy based solution and we explain why an endpoint-based 185 only solution is not considered acceptable. 187 It should be noted that this document addresses only _security_ use 188 cases with a focus on identifying the problematic ones. The document 189 does not offer specific solutions to these as the goal is to 190 stimulate further discussion and explore possible solutions 191 subsequently. 193 1.1. Requirements notation 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in RFC 198 2119, BCP 14 [RFC2119]. 200 2. TLS 1.3 Change Impact Overview 202 To improve its overall security and privacy, TLS 1.3 introduces 203 several changes to TLS 1.2; in doing so, some of the changes present 204 a negative impact on network based security. In this section, we 205 describe those TLS 1.3 changes and briefly outline some scenario 206 impacts. We divide the changes into two groups; those that impact 207 inbound sessions and those that impact outbound sessions. 209 2.1. Inbound Session Change Impacts 211 2.1.1. Removal of Static RSA and Diffie-Hellman Cipher Suites 213 TLS 1.2 supports static RSA and Diffie-Hellman cipher suites, which 214 enables the server's private key to be shared with server-side 215 middle-boxes. TLS 1.3 has removed support for these cipher suites in 216 favor of ephemeral mode Diffie-Hellman in order to provide perfect 217 forward secrecy (PFS). As a result of this, it is no longer possible 218 for a server to share a key with the middlebox a priori, which in 219 turn implies that the middlebox cannot gain access to the TLS session 220 data. 222 Example scenarios that are impacted by this include network 223 monitoring, troubleshooting, compliance, etc. 225 For further details (and a suggested solution), please refer to 226 [I-D.green-tls-static-dh-in-tls13]. 228 2.2. Outbound Session Change Impacts 230 2.2.1. Encrypted Server Certificate 232 In TLS 1.2, the ClientHello message is sent to the server's transport 233 address (IP and port). The ClientHello message may include the 234 Server Name Indication (SNI) to specify the actual server the client 235 wishes to contact. This is useful when multiple "virtual servers" 236 are hosted on a given transport address (IP and port). It also 237 provides information about the domain the client is attempting to 238 reach. 240 The server replies with a ServerHello message, which contains the 241 selected connection parameters, followed by a Certificate message, 242 which contains the server's certificate and hence its identity. 244 In TLS 1.2, the ClientHello, ServerHello and Certificate messages are 245 all sent in clear-text, however in TLS 1.3, the Certificate message 246 is encrypted thereby hiding the server identity from any 247 intermediary. Note that even _if_ the SNI is provided (in cleartext) 248 by the client, there is no guarantee that the actual server 249 responding is the one indicated in the SNI from the client. 251 Example scenarios that are impacted by this involve selective network 252 security, such as whitelists or blacklists based on security 253 intelligence, regulatory requirements, categories (e.g. financial 254 services), etc. An added challenge is that some of these scenarios 255 require the middlebox to perform inspection, whereas other scenarios 256 require the middlebox to _not_ perform inspection. Note that the use 257 cases cited here assume a conformant client and server that are not 258 actively trying to evade the middlebox inspection. A non-conformant 259 client and server that collude can always evade middlebox inspection 260 if the middlebox policy is based on information provided by the 261 client or server, such as SNI or certificate. 263 2.2.2. Resumption and Pre-Shared Key 265 In TLS 1.2 and below, session resumption is provided by "session IDs" 266 and "session tickets" [RFC5077]. If the server does not want to 267 honor a ticket, then it can simply initiate a full TLS handshake with 268 the client as usual. 270 In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), 271 which can be negotiated as part of an initial handshake and then used 272 in a subsequent handshake to perform resumption using the PSK. TLS 273 1.3 states that the client SHOULD include a "key_share" extension to 274 enable the server to decline resumption and fall back to a full 275 handshake, however it is not an absolute requirement. 277 Example scenarios that are impacted by this are middleboxes that were 278 not part of the initial handshake, and hence do not know the PSK. If 279 the client does not include the "key_share" extension, the middlebox 280 cannot force a fallback to the full handshake. If the middlebox 281 policy requires it to inspect the session, it will have to fail the 282 connection instead. 284 Note that in practice though, it is unlikely that clients using 285 session resumption will not allow for fallback to a full handshake 286 since the server may treat a ticket as valid for a shorter period of 287 time that what is stated in the ticket_lifetime [I-D.ietf-tls-tls13]. 289 As long as the client advertises a supported DH group, the server (or 290 middlebox) can always send a HelloRetryRequest to force the client to 291 send a key_share and hence a full handshake. 293 Clients that truly only support PSK mode of operation (provisioned 294 out of band) will of course not negotiate a new key, however that is 295 not a change in TLS 1.3. 297 2.2.3. Version Negotiation and Downgrade Protection 299 In TLS, the ClientHello message includes a list of supported protocol 300 versions. The server will select the highest supported version and 301 indicate its choice in the ServerHello message. 303 TLS 1.3 changes the way in which version negotiation is performed. 304 The ClientHello message will indicate TLS version 1.3 in the new 305 "supported_versions" extension, however for backwards compatibility 306 with TLS 1.2, the ClientHello message will indicate TLS version 1.2 307 in the "legacy_version" field. A TLS 1.3 server will recognize that 308 TLS 1.3 is being negotiated, whereas a TLS 1.2 server will simply see 309 a TLS 1.2 ClientHello and proceed with TLS 1.2 negotiation. 311 In TLS 1.3, the random value in the ServerHello message includes a 312 special value in the last eight bytes when the server negotiates 313 either TLS 1.2 or TLS 1.1 and below. The special value(s) enable a 314 TLS 1.3 client to detect an active attacker launching a downgrade 315 attack when the client did indeed reach a TLS 1.3 server, provided 316 ephemeral ciphers are being used. 318 From a network security point of view, the primary impact is that TLS 319 1.3 requires the TLS proxy to be an active man-in-the-middle from the 320 start of the handshake However, a middlebox that supports only TLS 321 1.2 may let the initial TLS 1.3 ClientHello proceed resulting in a 322 TLS 1.3 ServerHello from the server, which the middlebox does not 323 support. Depending on the policy configured, the TLS proxy may 324 reject the session at that point. 326 If the TLS 1.2 middlebox takes on an active role in the handshake 327 from the start, then the middlebox effectively proxies between a 328 client-to-middlebox and a middlebox-to-server TLS connection, in 329 which case the handshake succeeds (but as TLS 1.2). Note that due to 330 downgrade protection, the proxy cannot simply downgrade the TLS 331 version to 1.2 in the ClientHellow, which would enable it to 332 disengage from the handshake later. 334 2.2.4. SNI Encryption in TLS Through Tunneling 336 As noted above, with server certificates encrypted, the Server Name 337 Indication (SNI) in the ClientHello message is the only information 338 available in cleartext to indicate the client's targeted server, and 339 the actual server reached may differ. 341 [I-D.ietf-tls-sni-encryption] proposes to hide the SNI in the 342 ClientHello from middleboxes. 344 Example scenarios that are impacted by this involve selective network 345 security, such as whitelists or blacklists based on security 346 intelligence, regulatory requirements, categories (e.g. financial 347 services), etc. An added challenge is that some of these scenarios 348 require the middlebox to perform inspection, whereas other scenarios 349 require the middlebox to not perform inspection, however without the 350 SNI, the middlebox may not have the information required to determine 351 the actual scenario before it is too late. 353 3. Inbound Session Use Cases 355 In this section we explain how a set of inbound real-life inbound use 356 case scenarios are affected by some of the TLS 1.3 changes. 358 3.1. Use Case I1 - Data Center Protection 360 Services deployed in the data center may be offered for access by 361 external and untrusted hosts. Network security functions such as IPS 362 and Web Application Firewall (WAF) are deployed to monitor and 363 control the transactions to these services. While an Application 364 level load balancer is not a security function strictly speaking, it 365 is also an important function that resides in front of these services 367 These network security functions are usually deployed in two modes: 368 monitoring and inline. In either case, they need to access the L7 369 and application data such as HTTP transactions which could be 370 protected by TLS encryption. They may monitor the TLS handshakes for 371 additional visibility and control. 373 The TLS handshake monitoring function will be impacted by TLS 1.3. 375 For additional considerations on this scenario, see also 376 [I-D.green-tls-static-dh-in-tls13]. 378 3.2. Use Case I2 - Application Operation over NAT 380 The Network Address Translation (NAT) function translates L3 and L4 381 addresses and ports as the packet traverses the network device. 382 Sophisticated NAT devices may also implement application inspection 383 engines to correct L3/L4 data embedded in the control messages (e.g., 384 FTP control message, SIP signaling messages) so that they are 385 consistent with the outer L3/L4 headers. 387 Without the correction, the secondary data (FTP) or media (SIP) 388 connections will likely reach a wrong destination. 390 The embedded address and port correction operation requires access to 391 the L7 payload which could be protected by encryption. 393 While TLS 1.3 will not prevent the middlebox from performing this 394 function, once a proxy function is established, the middlebox is not 395 able to remove itself from the packet path for the particular 396 session. 398 3.3. Use Case I3 - Compliance 400 Many regulations exist today that include cyber security requirements 401 requiring close inspection of the information traversing through the 402 network. For example, organizations that require PCI-DSS [PCI-DSS] 403 compliance must provide the ability to regularly monitor the network 404 to prevent, detect and minimize impact of a data compromise. 405 [PCI-DSS] Requirement #2 (and Appendix A2 as it concerns TLS) 406 describes the need to be able to detect protocol and protocol usage 407 correctness. Further, [PCI-DSS] Requirement #10 detailing monitoring 408 capabilities also describe the need to provide network-based audit to 409 ensure that the protocols and configurations are properly used. 411 Deployments today still use factory or default credentials and 412 settings that must be observed, and to meet regulatory compliance, 413 must be audited, logged and reported. As the server (certificate) 414 credential is now encrypted in TLS 1.3, the ability to verify the 415 appropriate (or compliant) use of these credentials are lost, unless 416 the middlebox always becomes an active MITM. 418 3.4. Use Case I4 - Crypto Security Audit 420 Organizations may have policies around acceptable ciphers and 421 certificates on their servers. Examples include no use of self- 422 signed certificates, black or white-list Certificate Authority, etc. 423 In TLS 1.2, the Certificate message was sent in clear-text, however 424 in TLS 1.3 the message is encrypted thereby preventing either a 425 network-based audit or policy enforcement around acceptable server 426 certificates. 428 While the audits and policy enforcements could in theory be done on 429 the servers themselves, the premise of the use case is that not all 430 servers are configured correctly and hence such an approach is 431 unlikely to work in practice. A common example where this occurs 432 includes lab servers. 434 4. Outbound Session Use Cases 436 In this section we explain how a set of real-life outbound session 437 use case scenarios are affected by some of the TLS 1.3 changes. 439 4.1. Use Case O1 - Acceptable Use Policy (AUP) 441 Enterprises deploy security devices to enforce Acceptable Use Policy 442 (AUP) according to the IT and workplace policies. The security 443 devices, such as firewall/next-gen firewall, web proxy and an 444 application on the endpoints, act as middleboxes to scan traffic in 445 the enterprise network for policy enforcement. 447 Sample AUP policies are: 449 o "Employees are not allowed to access 'gaming' websites from 450 enterprise network" 452 o "Temporary workers are not allowed to use enterprise network to 453 upload video clips to Internet, but are allowed to watch video 454 clips" 456 Such enforcements are accomplished by controlling the DNS 457 transactions and HTTP transactions. A coarse control is achieved by 458 controlling the DNS response (which itself may be protected by TLS), 459 however, in many cases, granular control is required at HTTP URL or 460 Method levels, to distinguish a specific web page on a hosting site, 461 or to differentiate between uploading and downloading operations. 463 The security device requires access to plain text HTTP header for 464 granular AUP control. For traffic passing the AUP check, the 465 middlebox is also required to cut through the rest of the traffic 466 without decryption, for performance and privacy reasons. 468 The cut-through action is possible with up to TLS 1.2 but will not 469 work with TLS 1.3. 471 4.2. Use Case O2 - Malware and Threat Protection 473 Enterprises adopt a multi-technology approach when it comes to 474 malware and threat protection for the network assets. This includes 475 solutions deployed on the endpoint, network and cloud. 477 While an endpoint application based solution may be effective in 478 protecting from malware and virus attacks, enterprises prefer to 479 deploy multiple technologies for a multi-layer protection. Network 480 based solutions provide such additional protection with the benefit 481 of rapid and centralized updates. 483 The network based solutions comprise security devices and 484 applications that scan network traffic for the purpose from malware 485 signatures to 0-day analysis. 487 The security functions require access to clear text HTTP or other 488 application level streams on a needed basis. After a successful scan 489 the traffic should be allowed to flow through without being decrypted 490 continuously. This is not possible with TLS 1.3. 492 4.3. Use Case O3 - IoT Endpoints 494 As the Internet of Everything continues to evolve, more and more 495 endpoints become connected to the Internet. From a security point of 496 view, some of the challenges presented by these are: 498 o Constrained devices with limited resources (CPU, memory, etc.) 500 o Lack of ability to install and update endpoint protection 501 software. 503 o Lack of software updates as new vulnerabilities are discovered. 505 In short, the security posture of such devices is expected to be 506 weak, especially as they get older, and the only way to improve this 507 posture is to supplement them with a network-based solution. This in 508 turn requires a MITM, and with TLS 1.3, this implies the MITM must be 509 present at all times since the TLS 1.3 proxy must engage during the 510 ClientHello and cannot disengage subsequently. 512 4.4. Use Case O4 - Unpatched Endpoints 514 New vulnerabilities appear constantly and in spite of many advances 515 in recent years in terms of automated software updates, especially in 516 reaction to security vulnerabilities, the reality is that a very 517 large number of endpoints continue to run versions of software with 518 known vulnerabilities. 520 In theory, these endpoints should of course be patched, but in 521 practice, it is often not done which leaves the endpoint open to the 522 vulnerability in question. A network-based security solution can 523 look for attempted exploits of such vulnerabilities and stop them 524 before they reach the unpatched endpoint. 526 With TLS 1.3, the network-based security solution must act as a MITM 527 at all times, since it must engage during the ClientHello and cannot 528 disengage subsequently. 530 4.5. Use Case O5 - Rapid Containment of New Vulnerability and Campaigns 532 When a new vulnerability is discovered or an attack campaign is 533 launched, it is important to patch the vulnerability or contain the 534 campaign as quickly as possible. Patches however are not always 535 available immediately, and even when they are, most endpoints are in 536 practice not patched immediately, which leaves them open to the 537 attack. 539 A network-based security solution can look for attempted exploits of 540 such new vulnerabilities or recognize an attack being launched based 541 on security intelligence related to the campaign and stop them before 542 they reach the vulnerable endpoint. 544 With TLS 1.3, the network-based security solution must act as a MITM 545 at all times, since it must engage during the ClientHello and cannot 546 disengage subsequently. 548 4.6. Use Case O6 - End-of-Life Endpoint 550 Older endpoints (and in some cases even new ones) will not receive 551 any software updates. As new vulnerabilities inevitably are 552 discovered, these endpoints will be vulnerable to exploits. 554 A network-based security solution can help prevent such exploits. 555 With TLS 1.3, the network-based security solution must act as a MITM 556 at all times, since it must engage during the ClientHello and cannot 557 disengage subsequently. 559 4.7. Use Case O7 - Compliance 561 This use case is similar to the inbound compliance use case described 562 in Section 3.3, except its from the client point of view. 564 Again, the only way to satisfy the use case scenario around network- 565 based audit is for the middlebox to always become an active MITM. 567 4.8. Use Case O8 - Crypto Security Audit 569 This is a variation of the use case in Section 3.4. 571 Organizations may have policies around acceptable ciphers and 572 certificates for client sessions, possibly based on the destination. 573 Examples include no use of self-signed certificates, black or white- 574 list Certificate Authority, etc. In TLS 1.2, the Certificate message 575 was sent in clear-text, however in TLS 1.3 the message is encrypted 576 thereby preventing either a network-based audit or policy enforcement 577 around acceptable server certificates. 579 While the audits and policy enforcements could in theory be done on 580 the clients themselves, not all clients are configured correctly and 581 may not even be directly under configuration control of the 582 organization in question (e.g. due to Bring Your Own Device). 584 5. IANA considerations 586 This document does not include IANA considerations. 588 6. Security Considerations 590 This document describes existing functionality and use case scenarios 591 and as such does not introduce any new security considerations. 593 7. Acknowledgements 595 Eric Rescorla provided several comments on technical accuracy and 596 middlebox security implications. 598 8. Change Log 600 8.1. Version -01 602 Updates based on comments from Eric Rescorla. 604 9. References 606 9.1. Normative References 608 [I-D.ietf-tls-tls13] 609 Rescorla, E., "The Transport Layer Security (TLS) Protocol 610 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 611 March 2018. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 619 (TLS) Protocol Version 1.2", RFC 5246, 620 DOI 10.17487/RFC5246, August 2008, 621 . 623 9.2. Informative References 625 [BreakTLS] 626 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 627 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 628 Breaking and Fixing Authentication over TLS", IEEE 629 Symposium on Security and Privacy , 2014. 631 [HTTPSintercept] 632 Durumeric, Z., Ma, Z., Springall, D., Barnes, R., 633 Sullivan, N., Bursztein, E., Mailey, M., Halderman, J., 634 and V. Paxson, "The Security Impact of HTTPS 635 Interception", February 2017, 636 . 638 [I-D.green-tls-static-dh-in-tls13] 639 Green, M., Droms, R., Housley, R., Turner, P., and S. 640 Fenter, "Data Center use of Static Diffie-Hellman in TLS 641 1.3", draft-green-tls-static-dh-in-tls13-01 (work in 642 progress), July 2017. 644 [I-D.ietf-tls-sni-encryption] 645 Huitema, C. and E. Rescorla, "SNI Encryption in TLS 646 Through Tunneling", draft-ietf-tls-sni-encryption-02 (work 647 in progress), March 2018. 649 [NERCCIP] "North American Electric Reliability Corporation, (CIP) 650 Critical Infrastructure Protection", n.d., 651 . 654 [PCI-DSS] "Payment Card Industry (PCI): Data Security Standard", 655 April 2016, 656 . 659 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 660 "Transport Layer Security (TLS) Session Resumption without 661 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 662 January 2008, . 664 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 665 Langley, A., and M. Ray, "Transport Layer Security (TLS) 666 Session Hash and Extended Master Secret Extension", 667 RFC 7627, DOI 10.17487/RFC7627, September 2015, 668 . 670 Authors' Addresses 672 Flemming Andreasen 673 Cisco Systems 674 111 Wood Avenue South 675 Iselin, NJ 08830 676 USA 678 EMail: fandreas@cisco.com 680 Nancy Cam-Winget 681 Cisco Systems 682 3550 Cisco Way 683 San Jose, CA 95134 684 USA 686 EMail: ncamwing@cisco.com 688 Eric Wang 689 Cisco Systems 690 3550 Cisco Way 691 San Jose, CA 95134 692 USA 694 EMail: ejwang@cisco.com