idnits 2.17.1 draft-camwinget-tls-use-cases-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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 10, 2019) is 1867 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 (-09) exists of draft-ietf-tls-sni-encryption-04 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Andreasen 3 Internet-Draft N. Cam-Winget 4 Intended status: Informational E. Wang 5 Expires: September 11, 2019 Cisco Systems 6 March 10, 2019 8 TLS 1.3 Impact on Network-Based Security 9 draft-camwinget-tls-use-cases-04 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 enhance 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 and 19 deployments that adopt a multi-layered approach to security. While 20 this may be viewed as a feature, there are several real-life use case 21 scenarios where the same functionality and security can not be 22 offered without such network-based security solutions. In this 23 document, we identify the TLS 1.3 changes that may impact such use 24 cases. 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 11, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 1. Introduction 60 Enterprises, public sector, and cloud service providers need to 61 defend their information systems from attacks originating from both 62 inside and outside their networks. Protection and detection are 63 typically done both on end hosts and in the network. Host agents 64 have deep visibility on the devices where they are installed, whereas 65 the network has broader visibility. With such network and security 66 devices in the network, it can provide, among other functions, 67 homogenous security controls across heterogenous endpoints, covering 68 devices for which no host monitoring is available (which is common 69 today and is increasingly so in the Internet of Things). This helps 70 protect against unauthorized devices installed by insiders, and 71 provides a fallback in case the infection of a host disables its 72 security agent. Because of these advantages, network-based security 73 mechanisms are widely used. In fact, regulatory standards such as 74 NERC CIP [NERCCIP] place strong requirements about network perimeter 75 security and its ability to have visibility to provide security 76 information to the security management and control systems. At the 77 same time, the privacy of employees, customers, and other users must 78 be respected by minimizing the collection of personal data and 79 controlling access to what data is collected. These imperatives hold 80 for both end host and network based security monitoring. 82 Network-based security solutions such as Firewalls (FW) and Intrusion 83 Prevention Systems (IPS) rely on some level of network traffic 84 inspection to implement perimeter-based security policies. In many 85 use cases, only the metadata or visible aspects of the network 86 traffic is inspected. Depending on the security functions required, 87 these middleboxes can either be deployed as traffic monitoring 88 devices or active in-line devices. A traffic monitoring middlebox 89 may for example perform vulnerability detection, intrusion detection, 90 crypto audit, compliance monitoring, etc. An active in-line 91 middlebox may for example prevent malware download, block known 92 malicious URLs, enforce use of strong ciphers, stop data 93 exfiltration, etc. A portion of such security policies require 94 clear-text traffic inspection above Layer 4, which becomes 95 problematic when traffic is encrypted with Transport Layer Security 96 (TLS) [RFC5246]. Today, network-based security solutions typically 97 address this problem by becoming a man-in-the-middle (MITM) for the 98 TLS session according to one of the following two scenarios: 100 1. Outbound Session, where the TLS session originates from a client 101 inside the perimeter towards an entity on the outside 103 2. Inbound Session, where the TLS session originates from a client 104 outside the perimeter towards an entity on the inside 106 For the outbound session scenario, MITM is enabled by generating a 107 local root certificate and an accompanying (local) public/private key 108 pair. The local root certificate is installed on the inside entities 109 for which TLS traffic is to be inspected, and the network security 110 device(s) store a copy of the private key. During the TLS handshake, 111 the network security device (hereafter referred to as a middlebox) 112 makes a policy decision on the current TLS session. The policy 113 decision could be pass-through, decrypt, deny, etc. On a "decrypt" 114 policy action, the middlebox becomes a TLS proxy for this TLS 115 session. It modifies the certificate provided by the (outside) 116 server and (re)signs it with the private key from the local root 117 certificate. From here on, the middlebox has visibility into further 118 exchanges between the client and server which enables it to decrypt 119 and inspect subsequent network traffic. Alternatively, based on 120 policy, the middlebox may allow the current session to pass through 121 if the session starts in monitoring mode, and then decrypt the next 122 session from the same client. 124 For the inbound session scenario, the TLS proxy on the middlebox is 125 configured with a copy of the local servers' certificate(s) and 126 corresponding private key(s). Based on the server certificate 127 presented, the TLS proxy determines the corresponding private key, 128 which again enables the middlebox to gain visibility into further 129 exchanges between the client and server and hence decrypt subsequent 130 network traffic. 132 To date, there are a number of use case scenarios that rely on the 133 above capabilities when used with TLS 1.2 [RFC5246] or earlier. TLS 134 1.3 [RFC8446] introduces several changes which prevent a number of 135 these use case scenarios from being satisfied with the types of TLS 136 proxy based capabilities that exist today. 138 It has been noted, that currently deployed TLS proxies on middleboxes 139 may reduce the security of the TLS connection itself due to a 140 combination of poor implementation and configuration, and they may 141 compromise privacy when decrypting a TLS session. As such, it has 142 been argued that preventing TLS proxies from working should be viewed 143 as a feature of TLS 1.3 and that the proper way of solving these 144 issues is to solely rely on endpoint (client and server) based 145 solutions instead. We believe this is an overly constrained view of 146 the problem that ignores a number of important real-life use case 147 scenarios that improve the overall security posture. For instance, 148 it goes against a layered defense approach. We also note that 149 current endpoint-based TLS proxies suffer from many of the same 150 security issues as the network-based TLS proxies do [HTTPSintercept]. 152 The purpose of this document is to provide a representative set of 153 _network based security_ use case scenarios that are impacted by TLS 154 1.3. For each use case scenario, we highlight the specific aspect(s) 155 of TLS 1.3 that make the use case problematic with a TLS proxy based 156 solution. 158 It should be noted that this document addresses only _security_ use 159 cases with a focus on identifying the problematic ones. The document 160 does not offer specific solutions to these as the goal is to describe 161 how current network security solutions rely on network traffic 162 inspection to address customer requirements and use cases. 164 1.1. Requirements notation 166 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 167 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 168 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 169 [RFC2119]. 171 2. TLS 1.3 Change Impact Overview 173 Aiming to improve its overall security and privacy, TLS 1.3 174 introduces several changes to TLS 1.2, but some of the changes 175 present a negative impact on network based security. In this 176 section, we describe those TLS 1.3 changes and briefly outline some 177 scenario impacts. We divide the changes into two groups; those that 178 impact inbound sessions and those that impact outbound sessions. 180 2.1. Inbound Session Change Impacts 182 2.1.1. Removal of Static RSA and Diffie-Hellman Cipher Suites 184 TLS 1.2 supports static RSA and Diffie-Hellman(DH) cipher suites, 185 which enables the server's private key to be shared with server-side 186 middleboxes. TLS 1.3 has removed support for these cipher suites in 187 favor of supporting only ephemeral mode Diffie-Hellman in order to 188 provide perfect forward secrecy (PFS). As a result of this, it is no 189 longer possible for a server to share a key with the middlebox a 190 priori, which in turn implies that the middlebox cannot gain access 191 to the TLS session data. 193 Example scenarios that are impacted by this include network 194 monitoring, troubleshooting, compliance, etc. 196 For further details (and a suggested solution), please refer to 197 [I-D.green-tls-static-dh-in-tls13]. 199 2.2. Outbound Session Change Impacts 201 2.2.1. Encrypted Server Certificate 203 In TLS, the ClientHello message is sent to the server's transport 204 address (IP and port). The ClientHello message may include the 205 Server Name Indication (SNI) to specify the hostname the client 206 wishes to contact. This is useful when multiple "virtual servers" 207 are hosted on a given transport address (IP and port). It also 208 provides passive observers and security devices information about the 209 domain the client is attempting to reach. Note that while SNI is 210 optional in TLS 1.2, it is mandatory in TLS 1.3. 212 The server replies with a ServerHello message, which contains the 213 selected connection parameters, followed by a Certificate message, 214 which contains the server's certificate and hence its identity. 216 Note that even _if_ the SNI is provided by the client, there is no 217 guarantee that the actual server responding is the one indicated in 218 the SNI from the client. SNI alone, without comparison of the server 219 certificate, does not provide reliable information about the server 220 that the client attempts to reach. Where a client has been 221 compromised by malware and connects to a command and control server, 222 but presents an innocuous SNI to bypass protective filters, it is 223 undetectable under TLS 1.3. 225 In TLS 1.2, the ClientHello, ServerHello and Certificate messages are 226 all sent in clear-text, however in TLS 1.3, the Certificate message 227 is encrypted thereby hiding the server identity from any 228 intermediary. 230 Example scenarios that are impacted by this involve selective network 231 security policies on the server, such as whitelists or blacklists 232 based on security intelligence, regulatory requirements, categories 233 (e.g. financial services), etc. Under TLS 1.3, these scenarios now 234 require the middlebox to perform decryption and inspection of every 235 connection to have the same information to make policy decisions. 236 Further, the middlebox is not able to make the policy decisions 237 without actively engaging in the TLS 1.3 session from the beginning 238 of the handshake, and it cannot step out of the connection once it 239 has been determined to be benign, without dropping the whole 240 connection. In TLS 1.2, middleboxes could be more selective in 241 choosing what connections to engage with, and make decisions based on 242 the certificate without actively decrypting the connection to access 243 the certificate(s). 245 While conformant clients can generate the SNI and check that the 246 server certificate contains a name matching the SNI, there are non- 247 conformant clients that do not and some enterprises also require a 248 level of validation. Thus, from a network infrastructure 249 perspective, policies to validate SNI against the Server Certificate 250 can not be validated in TLS 1.3 as the Server certificate is now 251 obscured to the middlebox. This is an example where the network 252 infrastructure is using one measure to protect the enterprise from 253 non-conformant (e.g. evasive) clients and a conformant server. As a 254 general practice, security functions conduct cross checks and 255 consistency checks wherever possible to mitigate imperfect or 256 malicious implementations; even if they are deemed redundant with 257 fully conformant implementations. 259 2.2.2. Resumption and Pre-Shared Key 261 In TLS 1.2 and below, session resumption is provided by "session IDs" 262 and "session tickets" [RFC5077]. If the server does not want to 263 honor a ticket, then it can simply initiate a full TLS handshake with 264 the client as usual. 266 In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), 267 which can be negotiated as part of an initial handshake and then used 268 in a subsequent handshake to perform resumption using the PSK. TLS 269 1.3 states that the client SHOULD include a "key_share" extension to 270 enable the server to decline resumption and fall back to a full 271 handshake, however it is not an absolute requirement. 273 Example scenarios that are impacted by this are middleboxes that were 274 not part of the initial handshake, and hence do not know the PSK. If 275 the client does not include the "key_share" extension, the middlebox 276 cannot force a fallback to the full handshake. If the middlebox 277 policy requires it to inspect the session, it will have to fail the 278 connection instead. 280 Note that in practice though, it is unlikely that clients using 281 session resumption will not allow for fallback to a full handshake 282 since the server may treat a ticket as valid for a shorter period of 283 time that what is stated in the ticket_lifetime [RFC8446]. As long 284 as the client advertises a supported DH group, the server (or 285 middlebox) can always send a HelloRetryRequest to force the client to 286 send a key_share and hence a full handshake. 288 Clients that truly only support PSK mode of operation (provisioned 289 out of band) will of course not negotiate a new key, however that is 290 not a change in TLS 1.3. 292 2.2.3. Version Negotiation and Downgrade Protection 294 In TLS, the ClientHello message includes a list of supported protocol 295 versions. The server will select the highest supported version and 296 indicate its choice in the ServerHello message. 298 TLS 1.3 changes the way in which version negotiation is performed. 299 The ClientHello message will indicate TLS version 1.3 in the new 300 "supported_versions" extension, however for backwards compatibility 301 with TLS 1.2, the ClientHello message will indicate TLS version 1.2 302 in the "legacy_version" field. A TLS 1.3 server will recognize that 303 TLS 1.3 is being negotiated, whereas a TLS 1.2 server will simply see 304 a TLS 1.2 ClientHello and proceed with TLS 1.2 negotiation. 306 In TLS 1.3, the random value in the ServerHello message includes a 307 special value in the last eight bytes when the server negotiates 308 either TLS 1.2 or TLS 1.1 and below. The special value(s) enable a 309 TLS 1.3 client to detect an active attacker launching a downgrade 310 attack when the client did indeed reach a TLS 1.3 server, provided 311 ephemeral ciphers are being used. 313 From a network security point of view, the primary impact is that TLS 314 1.3 requires the TLS proxy to be an active man-in-the-middle from the 315 start of the handshake. It is also required that a TLS 1.2 and below 316 middlebox implementation must handle unsupported extensions 317 gracefully, which is a requirement for a conformant middlebox. 319 2.2.4. SNI Encryption in TLS Through Tunneling 321 As noted above, with server certificates encrypted, the Server Name 322 Indication (SNI) in the ClientHello message is the only information 323 available in cleartext to indicate the client's targeted server, and 324 the actual server reached may differ. 326 [I-D.ietf-tls-sni-encryption] proposes to hide the SNI in the 327 ClientHello from middleboxes. 329 Example scenarios that are impacted by this involve selective network 330 security, such as whitelists or blacklists based on security 331 intelligence, regulatory requirements, categories (e.g. financial 332 services), etc. An added challenge is that some of these scenarios 333 require the middlebox to perform inspection, whereas other scenarios 334 require the middlebox to not perform inspection. Without the SNI, 335 however, the middlebox may not have the information required to 336 determine the actual scenario before it is too late. 338 3. Inbound Session Use Cases 340 In this section we explain how a set of real-life inbound use case 341 scenarios are affected by some of the TLS 1.3 changes. 343 3.1. Use Case I1 - Data Center Protection 345 Services deployed in the data center may be offered for access by 346 external and untrusted hosts. Network security functions such as IPS 347 and Web Application Firewall (WAF) are deployed to monitor and 348 control the transactions to these services. While an Application 349 level load balancer is not a security function strictly speaking, it 350 is also an important function that resides in front of these services 352 These network security functions are usually deployed in two modes: 353 monitoring and inline. In either case, they need to access the L7 354 and application data such as HTTP transactions which could be 355 protected by TLS encryption. They may monitor the TLS handshakes for 356 additional visibility and control. 358 The TLS handshake monitoring function will be impacted by TLS 1.3. 360 For additional considerations on this scenario, see also 361 [I-D.green-tls-static-dh-in-tls13]. 363 3.2. Use Case I2 - Application Operation over NAT 365 The Network Address Translation (NAT) function translates L3 and L4 366 addresses and ports as the packet traverses the network device. 367 Sophisticated NAT devices may also implement application inspection 368 engines to correct L3/L4 data embedded in the control messages (e.g., 369 FTP control message, SIP signaling messages) so that they are 370 consistent with the outer L3/L4 headers. 372 Without the correction, the secondary data (FTP) or media (SIP) 373 connections will likely reach a wrong destination. 375 The embedded address and port correction operation requires access to 376 the L7 payload which could be protected by encryption. 378 3.3. Use Case I3 - Compliance 380 Many regulations exist today that include cyber security requirements 381 requiring close inspection of the information traversing through the 382 network. For example, organizations that require PCI-DSS [PCI-DSS] 383 compliance must provide the ability to regularly monitor the network 384 to prevent, detect and minimize impact of a data compromise. 385 [PCI-DSS] Requirement #2 (and Appendix A2 as it concerns TLS) 386 describes the need to be able to detect protocol and protocol usage 387 correctness. Further, [PCI-DSS] Requirement #10 detailing monitoring 388 capabilities also describe the need to provide network-based audit to 389 ensure that the protocols and configurations are properly used. 391 Deployments today still use factory or default credentials and 392 settings that must be observed, and to meet regulatory compliance, 393 must be audited, logged and reported. As the server (certificate) 394 credential is now encrypted in TLS 1.3, the ability to verify the 395 appropriate (or compliant) use of these credentials are lost, unless 396 the middlebox always becomes an active MITM. 398 3.4. Use Case I4 - Crypto Security Audit 400 Organizations may have policies around acceptable ciphers and 401 certificates on their servers. Examples include no use of self- 402 signed certificates, black or white-list Certificate Authority, valid 403 certificate experitation time, etc. In TLS 1.2, the Certificate 404 message was sent in clear-text, however in TLS 1.3 the message is 405 encrypted thereby preventing both a network-based audit and policy 406 enforcement around acceptable server certificates. 408 While the audits and policy enforcements could in theory be done on 409 the servers themselves, the premise of the use case is that not all 410 servers are configured correctly and hence such an approach is 411 unlikely to work in practice. A common example where this occurs 412 includes lab servers. 414 4. Outbound Session Use Cases 416 In this section we explain a set of real-life outbound session use 417 case scenarios. These scenarios remain functional with TLS 1.3 418 though the TLS proxy's performance is impacted by participating in 419 the DHE key exchange from the beginning of the handshake. Similarly, 420 while with TLS 1.2 the handshake packets could be passively 421 inspected, with TLS 1.3 the TLS proxy may have to perform full 422 decryption to inspect the certificates or to affect other policies 423 impacting its performance. 425 4.1. Use Case O1 - Acceptable Use Policy (AUP) 427 Enterprises deploy security devices to enforce Acceptable Use Policy 428 (AUP) according to the IT and workplace policies. The security 429 devices, such as firewall/next-gen firewall, web proxy and an 430 application on the endpoints, act as middleboxes to scan traffic in 431 the enterprise network for policy enforcement. 433 Sample AUP policies are: 435 o "Employees are not allowed to access 'gaming' websites from 436 enterprise network" 438 o "Temporary workers are not allowed to use enterprise network to 439 upload video clips to Internet, but are allowed to watch video 440 clips" 442 Such enforcements are accomplished by controlling the DNS 443 transactions and HTTP transactions. A coarse control can currently 444 be achieved by controlling the DNS response (though this may become 445 infeasible if it is also protected by TLS), however, in many cases, 446 granular control is required at HTTP URL or Method levels, to 447 distinguish a specific web page on a hosting site, or to 448 differentiate between uploading and downloading operations. 450 The security device requires access to plain text HTTP header for 451 granular AUP control. 453 4.2. Use Case O2 - Malware and Threat Protection 455 Enterprises adopt a multi-technology approach when it comes to 456 malware and threat protection for the network assets. This includes 457 solutions deployed on the endpoint, network and cloud. 459 While endpoint application based solution may be effective, to an 460 extent, at detecting and preventing some types of attack, defense in 461 depth is widely considered to be best security practice because it 462 provides additional protection against compromise of endpoints. For 463 example, network-based solutions can detect malware and threats based 464 on network visibility and provide discovery to a compromised 465 endpoint, even though the logs of such a compromised endpoint appear 466 normal. That is, network based solutions provide such additional 467 detection, prevention and mitigation of attacks with the benefit of 468 rapid and centralized updates. 470 The network based solutions utilise network traffic for a range of 471 purposes, including but not limited to: preventing malware landing on 472 the endpoint through signatures, detecting abnormal data 473 exfiltration, allowing 0-day analysis and mitigation of successful 474 attacks.". 476 The security functions require access to clear text HTTP or other 477 application level streams on a needed basis. 479 4.3. Use Case O3 - IoT Endpoints 481 As the Internet of Everything continues to evolve, more and more 482 endpoints become connected to the Internet. From a security point of 483 view, some of the challenges presented by these are: 485 o Constrained devices with limited resources (CPU, memory, battery 486 life, etc.) 488 o Lack of ability to install and update endpoint protection 489 software. 491 o Lack of software updates as new vulnerabilities are discovered. 493 In short, the security posture of such devices is expected to be 494 weak, especially as they get older, and the only way to improve this 495 posture is to supplement them with a network-based solution. IoT 496 deployments are further challenged in that they host a variety of 497 these devices, each with different update cycles and often, are very 498 slot to update their software or firmware to ensure availability and 499 safe of the environments they operate. This in turn requires network 500 based solutions to afford a consistant security baseline. This 501 solution can range from selective passive monitoring to a full and 502 active MiTM. 504 4.4. Use Case O4 - Unpatched Endpoints 506 New vulnerabilities appear constantly and in spite of many advances 507 in recent years in terms of automated software updates, especially in 508 reaction to security vulnerabilities, the reality is that a very 509 large number of endpoints continue to run versions of software with 510 known vulnerabilities. 512 In theory, these endpoints should of course be patched, but in 513 practice, it is often not done which leaves the endpoint open to the 514 vulnerability in question. A network-based security solution can 515 look for attempted exploits of such vulnerabilities and stop them 516 before they reach the unpatched endpoint. 518 4.5. Use Case O5 - Rapid Containment of New Vulnerability and Campaigns 520 When a new vulnerability is discovered or an attack campaign is 521 launched, it is important to patch the vulnerability or contain the 522 campaign as quickly as possible. Patches however are not usually 523 available immediately for every device on the network, and even when 524 they are, most endpoints are in practice not patched immediately, 525 which leaves them open to the attack. 527 A network-based security solution can look for attempted exploits of 528 such new vulnerabilities or recognize an attack being launched based 529 on security intelligence related to the campaign and stop them before 530 they reach the vulnerable endpoint. 532 4.6. Use Case O6 - End-of-Life Endpoint 534 Older endpoints (and in some cases even new ones) will not receive 535 any software updates. As new vulnerabilities inevitably are 536 discovered, these endpoints will be permanently vulnerable to 537 exploits without security solutions that are not endpoint-based. 539 A network-based security solution can help prevent such exploits with 540 the MITM functions. 542 4.7. Use Case O7 - Compliance 544 This use case is similar to the inbound compliance use case described 545 in Section 3.3, except its from the client point of view. 547 4.8. Use Case O8 - Crypto Security Audit 549 This is a variation of the use case in Section 3.4. 551 Organizations may have policies around acceptable ciphers and 552 certificates for client sessions, possibly based on the destination. 553 Examples include no use of self-signed certificates, black or white- 554 list Certificate Authority, etc. In TLS 1.2, the Certificate message 555 was sent in clear-text, however in TLS 1.3 the message is encrypted 556 thereby preventing either a network-based audit or policy enforcement 557 around acceptable server certificates. 559 It is not possible to implement a full security solution by relying 560 on the client alone in this case. For example, in the many cases 561 where the device is not under configuration control of the 562 organisation (i.e. "Bring Your Own Device" devices, which are 563 present in many modern organisations), as audits and policy 564 enforcements can't be done on such clients or on clients that are not 565 properly configured. 567 5. IANA considerations 569 This document does not include IANA considerations. 571 6. Security Considerations 573 This document describes existing functionality and use case scenarios 574 and as such does not introduce any new security considerations. 576 7. Acknowledgements 578 The authors thank Eric Rescorla and the National Cyber Security 579 Center who provided several comments on technical accuracy and 580 middlebox security implications. 582 8. Change Log 584 8.1. Version -01 586 Updates based on comments from Eric Rescorla. 588 8.2. Version -03 590 Updates based on EKR's comments 592 9. Version -04 594 Updates based on Kirsty's comments 596 10. References 598 10.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, 602 DOI 10.17487/RFC2119, March 1997, 603 . 605 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 606 (TLS) Protocol Version 1.2", RFC 5246, 607 DOI 10.17487/RFC5246, August 2008, 608 . 610 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 611 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 612 . 614 10.2. Informative References 616 [HTTPSintercept] 617 "The Security Impact of HTTPS Interception", n.d., 618 . 620 [I-D.green-tls-static-dh-in-tls13] 621 Green, M., Droms, R., Housley, R., Turner, P., and S. 622 Fenter, "Data Center use of Static Diffie-Hellman in TLS 623 1.3", draft-green-tls-static-dh-in-tls13-01 (work in 624 progress), July 2017. 626 [I-D.ietf-tls-sni-encryption] 627 Huitema, C. and E. Rescorla, "Issues and Requirements for 628 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04 629 (work in progress), November 2018. 631 [NERCCIP] "North American Electric Reliability Corporation, (CIP) 632 Critical Infrastructure Protection", n.d., 633 . 636 [PCI-DSS] "Payment Card Industry (PCI): Data Security Standard", 637 n.d., . 640 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 641 "Transport Layer Security (TLS) Session Resumption without 642 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 643 January 2008, . 645 Authors' Addresses 647 Flemming Andreasen 648 Cisco Systems 649 111 Wood Avenue South 650 Iselin, NJ 08830 651 USA 653 Email: fandreas@cisco.com 655 Nancy Cam-Winget 656 Cisco Systems 657 3550 Cisco Way 658 San Jose, CA 95134 659 USA 661 Email: ncamwing@cisco.com 662 Eric Wang 663 Cisco Systems 664 3550 Cisco Way 665 San Jose, CA 95134 666 USA 668 Email: ejwang@cisco.com