idnits 2.17.1 draft-camwinget-tls-use-cases-03.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 (December 29, 2018) is 1945 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: July 2, 2019 Cisco Systems 6 December 29, 2018 8 TLS 1.3 Impact on Network-Based Security 9 draft-camwinget-tls-use-cases-03 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 July 2, 2019. 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 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 and provides homogenous security 66 controls across heterogenous endpoints, covering devices for which no 67 host monitoring is available (which is common today and is 68 increasingly so in the Internet of Things). This helps protect 69 against unauthorized devices installed by insiders, and provides a 70 fallback in case the infection of a host disables its security agent. 71 Because of these advantages, network-based security mechanisms are 72 widely used. In fact, regulatory standards such as NERC CIP 73 [NERCCIP] place strong requirements about network perimeter security 74 and its ability to have visibility to provide security information to 75 the security management and control systems. At the same time, the 76 privacy of employees, customers, and other users must be respected by 77 minimizing the collection of personal data and controlling access to 78 what data is collected. These imperatives hold for both end host and 79 network based security monitoring. 81 Network-based security solutions such as Firewalls (FW) and Intrusion 82 Prevention Systems (IPS) rely on network traffic inspection to 83 implement perimeter-based security policies. Depending on the 84 security functions required, these middleboxes can either be deployed 85 as traffic monitoring devices or active in-line devices. A traffic 86 monitoring middlebox may for example perform vulnerability detection, 87 intrusion detection, crypto audit, compliance monitoring, etc. An 88 active in-line middlebox may for example prevent malware download, 89 block known malicious URLs, enforce use of strong ciphers, stop data 90 exfiltration, etc. A significant portion of such security policies 91 require clear-text traffic inspection above Layer 4, which becomes 92 problematic when traffic is encrypted with Transport Layer Security 93 (TLS) [RFC5246]. Today, network-based security solutions typically 94 address this problem by becoming a man-in-the-middle (MITM) for the 95 TLS session according to one of the following two scenarios: 97 1. Outbound Session, where the TLS session originates from a client 98 inside the perimeter towards an entity on the outside 100 2. Inbound Session, where the TLS session originates from a client 101 outside the perimeter towards an entity on the inside 103 For the outbound session scenario, MITM is enabled by generating a 104 local root certificate and an accompanying (local) public/private key 105 pair. The local root certificate is installed on the inside entities 106 for which TLS traffic is to be inspected, and the network security 107 device(s) store a copy of the private key. During the TLS handshake, 108 the network security device (hereafter referred to as a middlebox) 109 makes a policy decision on the current TLS session. The policy 110 decision could be pass-through, decrypt, deny, etc. On a "decrypt" 111 policy action, the middlebox becomes a TLS proxy for this TLS 112 session. It modifies the certificate provided by the (outside) 113 server and (re)signs it with the private key from the local root 114 certificate. From here on, the middlebox has visibility into further 115 exchanges between the client and server which enables it to decrypt 116 and inspect subsequent network traffic. Alternatively, based on 117 policy, the middlebox may allow the current session to pass through 118 if the session starts in monitoring mode, and then decrypt the next 119 session from the same client. 121 For the inbound session scenario, the TLS proxy on the middlebox is 122 configured with a copy of the local servers' certificate(s) and 123 corresponding private key(s). Based on the server certificate 124 presented, the TLS proxy determines the corresponding private key, 125 which again enables the middlebox to gain visibility into further 126 exchanges between the client and server and hence decrypt subsequent 127 network traffic. 129 To date, there are a number of use case scenarios that rely on the 130 above capabilities when used with TLS 1.2 [RFC5246] or earlier. TLS 131 1.3 [RFC8446] introduces several changes which prevent a number of 132 these use case scenarios from being satisfied with the types of TLS 133 proxy based capabilities that exist today. 135 It has been noted, that currently deployed TLS proxies on middleboxes 136 may reduce the security of the TLS connection itself due to a 137 combination of poor implementation and configuration, and they may 138 compromise privacy when decrypting a TLS session. As such, it has 139 been argued that preventing TLS proxies from working should be viewed 140 as a feature of TLS 1.3 and that the proper way of solving these 141 issues is to rely on endpoint (client and server) based solutions 142 instead. We believe this is an overly constrained view of the 143 problem that ignores a number of important real-life use case 144 scenarios that improve the overall security posture. We also note 145 that current endpoint-based TLS proxies suffer from many of the same 146 security issues as the network-based TLS proxies do [HTTPSintercept]. 148 The purpose of this document is to provide a representative set of 149 _network based security_ use case scenarios that are impacted by TLS 150 1.3. For each use case scenario, we highlight the specific aspect(s) 151 of TLS 1.3 that may make the use case problematic with a TLS proxy 152 based solution. 154 It should be noted that this document addresses only _security_ use 155 cases with a focus on identifying the problematic ones. The document 156 does not offer specific solutions to these as the goal is to 157 stimulate further discussion and explore possible solutions 158 subsequently. 160 1.1. Requirements notation 162 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 163 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 164 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 165 [RFC2119]. 167 2. TLS 1.3 Change Impact Overview 169 To improve its overall security and privacy, TLS 1.3 introduces 170 several changes to TLS 1.2; in doing so, some of the changes present 171 a negative impact on network based security. In this section, we 172 describe those TLS 1.3 changes and briefly outline some scenario 173 impacts. We divide the changes into two groups; those that impact 174 inbound sessions and those that impact outbound sessions. 176 2.1. Inbound Session Change Impacts 178 2.1.1. Removal of Static RSA and Diffie-Hellman Cipher Suites 180 TLS 1.2 supports static RSA and Diffie-Hellman cipher suites, which 181 enables the server's private key to be shared with server-side 182 middleboxes. TLS 1.3 has removed support for these cipher suites in 183 favor of ephemeral mode Diffie-Hellman in order to provide perfect 184 forward secrecy (PFS). As a result of this, it is no longer possible 185 for a server to share a key with the middlebox a priori, which in 186 turn implies that the middlebox cannot gain access to the TLS session 187 data. 189 Example scenarios that are impacted by this include network 190 monitoring, troubleshooting, compliance, etc. 192 For further details (and a suggested solution), please refer to 193 [I-D.green-tls-static-dh-in-tls13]. 195 2.2. Outbound Session Change Impacts 197 2.2.1. Encrypted Server Certificate 199 In TLS, the ClientHello message is sent to the server's transport 200 address (IP and port). The ClientHello message may include the 201 Server Name Indication (SNI) to specify the hostname the client 202 wishes to contact. This is useful when multiple "virtual servers" 203 are hosted on a given transport address (IP and port). It also 204 provides information about the domain the client is attempting to 205 reach. 207 The server replies with a ServerHello message, which contains the 208 selected connection parameters, followed by a Certificate message, 209 which contains the server's certificate and hence its identity. 211 Note that even _if_ the SNI is provided by the client, there is no 212 guarantee that the actual server responding is the one indicated in 213 the SNI from the client. SNI alone does not provide reliable 214 information about the server that the client attempts to reach. 216 In TLS 1.2, the ClientHello, ServerHello and Certificate messages are 217 all sent in clear-text, however in TLS 1.3, the Certificate message 218 is encrypted thereby hiding the server identity from any 219 intermediary. 221 Example scenarios that are impacted by this involve selective network 222 security policies on the server, such as whitelists or blacklists 223 based on security intelligence, regulatory requirements, categories 224 (e.g. financial services), etc. An added challenge is that some of 225 these scenarios require the middlebox to perform decryption and 226 inspection, whereas other scenarios require the middlebox to _not_ 227 perform decryption or inspection. The middlebox is not able to make 228 the policy decisions without actively engaging in the TLS session 229 from the beginning of the handshake. 231 While conformant clients can generate the SNI and check that the 232 server certificate contains a name matching the SNI; some enterprises 233 also require a level of validation. Thus, from a network 234 infrastructure perspective, policies to validate SNI against the 235 Server Certificate can not be validated in TLS 1.3 as the Server 236 certificate is now obscured to the middlebox. This is an example 237 where the network infrastructure is using one measure to protect the 238 enterprise from non-conformant (e.g. evasive) clients and a 239 conformant server. As a general practice, security functions conduct 240 cross checks and consistency checks wherever possible to mitigate 241 imperfect or malicious implementations; even if they are deemed 242 redundant with fully conformant implementations. 244 2.2.2. Resumption and Pre-Shared Key 246 In TLS 1.2 and below, session resumption is provided by "session IDs" 247 and "session tickets" [RFC5077]. If the server does not want to 248 honor a ticket, then it can simply initiate a full TLS handshake with 249 the client as usual. 251 In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), 252 which can be negotiated as part of an initial handshake and then used 253 in a subsequent handshake to perform resumption using the PSK. TLS 254 1.3 states that the client SHOULD include a "key_share" extension to 255 enable the server to decline resumption and fall back to a full 256 handshake, however it is not an absolute requirement. 258 Example scenarios that are impacted by this are middleboxes that were 259 not part of the initial handshake, and hence do not know the PSK. If 260 the client does not include the "key_share" extension, the middlebox 261 cannot force a fallback to the full handshake. If the middlebox 262 policy requires it to inspect the session, it will have to fail the 263 connection instead. 265 Note that in practice though, it is unlikely that clients using 266 session resumption will not allow for fallback to a full handshake 267 since the server may treat a ticket as valid for a shorter period of 268 time that what is stated in the ticket_lifetime [RFC8446]. As long 269 as the client advertises a supported DH group, the server (or 270 middlebox) can always send a HelloRetryRequest to force the client to 271 send a key_share and hence a full handshake. 273 Clients that truly only support PSK mode of operation (provisioned 274 out of band) will of course not negotiate a new key, however that is 275 not a change in TLS 1.3. 277 2.2.3. Version Negotiation and Downgrade Protection 279 In TLS, the ClientHello message includes a list of supported protocol 280 versions. The server will select the highest supported version and 281 indicate its choice in the ServerHello message. 283 TLS 1.3 changes the way in which version negotiation is performed. 284 The ClientHello message will indicate TLS version 1.3 in the new 285 "supported_versions" extension, however for backwards compatibility 286 with TLS 1.2, the ClientHello message will indicate TLS version 1.2 287 in the "legacy_version" field. A TLS 1.3 server will recognize that 288 TLS 1.3 is being negotiated, whereas a TLS 1.2 server will simply see 289 a TLS 1.2 ClientHello and proceed with TLS 1.2 negotiation. 291 In TLS 1.3, the random value in the ServerHello message includes a 292 special value in the last eight bytes when the server negotiates 293 either TLS 1.2 or TLS 1.1 and below. The special value(s) enable a 294 TLS 1.3 client to detect an active attacker launching a downgrade 295 attack when the client did indeed reach a TLS 1.3 server, provided 296 ephemeral ciphers are being used. 298 From a network security point of view, the primary impact is that TLS 299 1.3 requires the TLS proxy to be an active man-in-the-middle from the 300 start of the handshake. It is also required that a TLS 1.2 and below 301 middlebox implementation must handle unsupported extensions 302 gracefully, which is a requirement for a conformant middlebox. 304 2.2.4. SNI Encryption in TLS Through Tunneling 306 As noted above, with server certificates encrypted, the Server Name 307 Indication (SNI) in the ClientHello message is the only information 308 available in cleartext to indicate the client's targeted server, and 309 the actual server reached may differ. 311 [I-D.ietf-tls-sni-encryption] proposes to hide the SNI in the 312 ClientHello from middleboxes. 314 Example scenarios that are impacted by this involve selective network 315 security, such as whitelists or blacklists based on security 316 intelligence, regulatory requirements, categories (e.g. financial 317 services), etc. An added challenge is that some of these scenarios 318 require the middlebox to perform inspection, whereas other scenarios 319 require the middlebox to not perform inspection, however without the 320 SNI, the middlebox may not have the information required to determine 321 the actual scenario before it is too late. 323 3. Inbound Session Use Cases 325 In this section we explain how a set of inbound real-life inbound use 326 case scenarios are affected by some of the TLS 1.3 changes. 328 3.1. Use Case I1 - Data Center Protection 330 Services deployed in the data center may be offered for access by 331 external and untrusted hosts. Network security functions such as IPS 332 and Web Application Firewall (WAF) are deployed to monitor and 333 control the transactions to these services. While an Application 334 level load balancer is not a security function strictly speaking, it 335 is also an important function that resides in front of these services 336 These network security functions are usually deployed in two modes: 337 monitoring and inline. In either case, they need to access the L7 338 and application data such as HTTP transactions which could be 339 protected by TLS encryption. They may monitor the TLS handshakes for 340 additional visibility and control. 342 The TLS handshake monitoring function will be impacted by TLS 1.3. 344 For additional considerations on this scenario, see also 345 [I-D.green-tls-static-dh-in-tls13]. 347 3.2. Use Case I2 - Application Operation over NAT 349 The Network Address Translation (NAT) function translates L3 and L4 350 addresses and ports as the packet traverses the network device. 351 Sophisticated NAT devices may also implement application inspection 352 engines to correct L3/L4 data embedded in the control messages (e.g., 353 FTP control message, SIP signaling messages) so that they are 354 consistent with the outer L3/L4 headers. 356 Without the correction, the secondary data (FTP) or media (SIP) 357 connections will likely reach a wrong destination. 359 The embedded address and port correction operation requires access to 360 the L7 payload which could be protected by encryption. 362 3.3. Use Case I3 - Compliance 364 Many regulations exist today that include cyber security requirements 365 requiring close inspection of the information traversing through the 366 network. For example, organizations that require PCI-DSS [PCI-DSS] 367 compliance must provide the ability to regularly monitor the network 368 to prevent, detect and minimize impact of a data compromise. 369 [PCI-DSS] Requirement #2 (and Appendix A2 as it concerns TLS) 370 describes the need to be able to detect protocol and protocol usage 371 correctness. Further, [PCI-DSS] Requirement #10 detailing monitoring 372 capabilities also describe the need to provide network-based audit to 373 ensure that the protocols and configurations are properly used. 375 Deployments today still use factory or default credentials and 376 settings that must be observed, and to meet regulatory compliance, 377 must be audited, logged and reported. As the server (certificate) 378 credential is now encrypted in TLS 1.3, the ability to verify the 379 appropriate (or compliant) use of these credentials are lost, unless 380 the middlebox always becomes an active MITM. 382 3.4. Use Case I4 - Crypto Security Audit 384 Organizations may have policies around acceptable ciphers and 385 certificates on their servers. Examples include no use of self- 386 signed certificates, black or white-list Certificate Authority, etc. 387 In TLS 1.2, the Certificate message was sent in clear-text, however 388 in TLS 1.3 the message is encrypted thereby preventing either a 389 network-based audit or policy enforcement around acceptable server 390 certificates. 392 While the audits and policy enforcements could in theory be done on 393 the servers themselves, the premise of the use case is that not all 394 servers are configured correctly and hence such an approach is 395 unlikely to work in practice. A common example where this occurs 396 includes lab servers. 398 4. Outbound Session Use Cases 400 In this section we explain a set of real-life outbound session use 401 case scenarios. These scenarios remain functional with TLS 1.3 402 though the TLS proxy's performance is impacted by participating in 403 the DHE key exchange from the beginning of the handshake. 405 4.1. Use Case O1 - Acceptable Use Policy (AUP) 407 Enterprises deploy security devices to enforce Acceptable Use Policy 408 (AUP) according to the IT and workplace policies. The security 409 devices, such as firewall/next-gen firewall, web proxy and an 410 application on the endpoints, act as middleboxes to scan traffic in 411 the enterprise network for policy enforcement. 413 Sample AUP policies are: 415 o "Employees are not allowed to access 'gaming' websites from 416 enterprise network" 418 o "Temporary workers are not allowed to use enterprise network to 419 upload video clips to Internet, but are allowed to watch video 420 clips" 422 Such enforcements are accomplished by controlling the DNS 423 transactions and HTTP transactions. A coarse control is achieved by 424 controlling the DNS response (which itself may be protected by TLS), 425 however, in many cases, granular control is required at HTTP URL or 426 Method levels, to distinguish a specific web page on a hosting site, 427 or to differentiate between uploading and downloading operations. 429 The security device requires access to plain text HTTP header for 430 granular AUP control. 432 4.2. Use Case O2 - Malware and Threat Protection 434 Enterprises adopt a multi-technology approach when it comes to 435 malware and threat protection for the network assets. This includes 436 solutions deployed on the endpoint, network and cloud. 438 While an endpoint application based solution may be effective in 439 protecting from malware and virus attacks, enterprises prefer to 440 deploy multiple technologies for a multi-layer protection. Network 441 based solutions provide such additional protection with the benefit 442 of rapid and centralized updates. 444 The network based solutions comprise security devices and 445 applications that scan network traffic for the purpose from malware 446 signatures to 0-day analysis. 448 The security functions require access to clear text HTTP or other 449 application level streams on a needed basis. 451 4.3. Use Case O3 - IoT Endpoints 453 As the Internet of Everything continues to evolve, more and more 454 endpoints become connected to the Internet. From a security point of 455 view, some of the challenges presented by these are: 457 o Constrained devices with limited resources (CPU, memory, etc.) 459 o Lack of ability to install and update endpoint protection 460 software. 462 o Lack of software updates as new vulnerabilities are discovered. 464 In short, the security posture of such devices is expected to be 465 weak, especially as they get older, and the only way to improve this 466 posture is to supplement them with a network-based solution. This in 467 turn requires a MITM. 469 4.4. Use Case O4 - Unpatched Endpoints 471 New vulnerabilities appear constantly and in spite of many advances 472 in recent years in terms of automated software updates, especially in 473 reaction to security vulnerabilities, the reality is that a very 474 large number of endpoints continue to run versions of software with 475 known vulnerabilities. 477 In theory, these endpoints should of course be patched, but in 478 practice, it is often not done which leaves the endpoint open to the 479 vulnerability in question. A network-based security solution can 480 look for attempted exploits of such vulnerabilities and stop them 481 before they reach the unpatched endpoint. 483 4.5. Use Case O5 - Rapid Containment of New Vulnerability and Campaigns 485 When a new vulnerability is discovered or an attack campaign is 486 launched, it is important to patch the vulnerability or contain the 487 campaign as quickly as possible. Patches however are not always 488 available immediately, and even when they are, most endpoints are in 489 practice not patched immediately, which leaves them open to the 490 attack. 492 A network-based security solution can look for attempted exploits of 493 such new vulnerabilities or recognize an attack being launched based 494 on security intelligence related to the campaign and stop them before 495 they reach the vulnerable endpoint. 497 4.6. Use Case O6 - End-of-Life Endpoint 499 Older endpoints (and in some cases even new ones) will not receive 500 any software updates. As new vulnerabilities inevitably are 501 discovered, these endpoints will be vulnerable to exploits. 503 A network-based security solution can help prevent such exploits with 504 the MITM functions. 506 4.7. Use Case O7 - Compliance 508 This use case is similar to the inbound compliance use case described 509 in Section 3.3, except its from the client point of view. 511 4.8. Use Case O8 - Crypto Security Audit 513 This is a variation of the use case in Section 3.4. 515 Organizations may have policies around acceptable ciphers and 516 certificates for client sessions, possibly based on the destination. 517 Examples include no use of self-signed certificates, black or white- 518 list Certificate Authority, etc. In TLS 1.2, the Certificate message 519 was sent in clear-text, however in TLS 1.3 the message is encrypted 520 thereby preventing either a network-based audit or policy enforcement 521 around acceptable server certificates. 523 While the audits and policy enforcements could in theory be done on 524 the clients themselves, not all clients are configured correctly and 525 may not even be directly under configuration control of the 526 organization in question (e.g. due to Bring Your Own Device). 528 5. IANA considerations 530 This document does not include IANA considerations. 532 6. Security Considerations 534 This document describes existing functionality and use case scenarios 535 and as such does not introduce any new security considerations. 537 7. Acknowledgements 539 The authors thank Eric Rescorla who provided several comments on 540 technical accuracy and middlebox security implications. 542 8. Change Log 544 8.1. Version -01 546 Updates based on comments from Eric Rescorla. 548 8.2. Version -03 550 Updates based on EKR's comments 552 9. References 554 9.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 562 (TLS) Protocol Version 1.2", RFC 5246, 563 DOI 10.17487/RFC5246, August 2008, 564 . 566 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 567 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 568 . 570 9.2. Informative References 572 [HTTPSintercept] 573 "The Security Impact of HTTPS Interception", n.d., 574 . 576 [I-D.green-tls-static-dh-in-tls13] 577 Green, M., Droms, R., Housley, R., Turner, P., and S. 578 Fenter, "Data Center use of Static Diffie-Hellman in TLS 579 1.3", draft-green-tls-static-dh-in-tls13-01 (work in 580 progress), July 2017. 582 [I-D.ietf-tls-sni-encryption] 583 Huitema, C. and E. Rescorla, "Issues and Requirements for 584 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04 585 (work in progress), November 2018. 587 [NERCCIP] "North American Electric Reliability Corporation, (CIP) 588 Critical Infrastructure Protection", n.d., 589 . 592 [PCI-DSS] "Payment Card Industry (PCI): Data Security Standard", 593 n.d., . 596 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 597 "Transport Layer Security (TLS) Session Resumption without 598 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 599 January 2008, . 601 Authors' Addresses 603 Flemming Andreasen 604 Cisco Systems 605 111 Wood Avenue South 606 Iselin, NJ 08830 607 USA 609 Email: fandreas@cisco.com 610 Nancy Cam-Winget 611 Cisco Systems 612 3550 Cisco Way 613 San Jose, CA 95134 614 USA 616 Email: ncamwing@cisco.com 618 Eric Wang 619 Cisco Systems 620 3550 Cisco Way 621 San Jose, CA 95134 622 USA 624 Email: ejwang@cisco.com