idnits 2.17.1 draft-camwinget-tls-use-cases-02.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 (July 02, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7627' is defined on line 593, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-03 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 4 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: January 3, 2019 Cisco Systems 6 July 02, 2018 8 TLS 1.3 Impact on Network-Based Security 9 draft-camwinget-tls-use-cases-02 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 January 3, 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 [I-D.ietf-tls-tls13] introduces several changes which prevent a 132 number of these use case scenarios from being satisfied with the 133 types of TLS 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 From a network infrastructure perspective, policies to validate SNI 232 against the Server Certificate can not be validated as the Server 233 certificate is now obscured to the middlebox. Furthermore, policies 234 that may require richer information about the TLS Server obtained 235 from the Server certificate are also impacted as the certficate is 236 now encrypted. 238 2.2.2. Resumption and Pre-Shared Key 240 In TLS 1.2 and below, session resumption is provided by "session IDs" 241 and "session tickets" [RFC5077]. If the server does not want to 242 honor a ticket, then it can simply initiate a full TLS handshake with 243 the client as usual. 245 In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), 246 which can be negotiated as part of an initial handshake and then used 247 in a subsequent handshake to perform resumption using the PSK. TLS 248 1.3 states that the client SHOULD include a "key_share" extension to 249 enable the server to decline resumption and fall back to a full 250 handshake, however it is not an absolute requirement. 252 Example scenarios that are impacted by this are middleboxes that were 253 not part of the initial handshake, and hence do not know the PSK. If 254 the client does not include the "key_share" extension, the middlebox 255 cannot force a fallback to the full handshake. If the middlebox 256 policy requires it to inspect the session, it will have to fail the 257 connection instead. 259 Note that in practice though, it is unlikely that clients using 260 session resumption will not allow for fallback to a full handshake 261 since the server may treat a ticket as valid for a shorter period of 262 time that what is stated in the ticket_lifetime [I-D.ietf-tls-tls13]. 263 As long as the client advertises a supported DH group, the server (or 264 middlebox) can always send a HelloRetryRequest to force the client to 265 send a key_share and hence a full handshake. 267 Clients that truly only support PSK mode of operation (provisioned 268 out of band) will of course not negotiate a new key, however that is 269 not a change in TLS 1.3. 271 2.2.3. Version Negotiation and Downgrade Protection 273 In TLS, the ClientHello message includes a list of supported protocol 274 versions. The server will select the highest supported version and 275 indicate its choice in the ServerHello message. 277 TLS 1.3 changes the way in which version negotiation is performed. 278 The ClientHello message will indicate TLS version 1.3 in the new 279 "supported_versions" extension, however for backwards compatibility 280 with TLS 1.2, the ClientHello message will indicate TLS version 1.2 281 in the "legacy_version" field. A TLS 1.3 server will recognize that 282 TLS 1.3 is being negotiated, whereas a TLS 1.2 server will simply see 283 a TLS 1.2 ClientHello and proceed with TLS 1.2 negotiation. 285 In TLS 1.3, the random value in the ServerHello message includes a 286 special value in the last eight bytes when the server negotiates 287 either TLS 1.2 or TLS 1.1 and below. The special value(s) enable a 288 TLS 1.3 client to detect an active attacker launching a downgrade 289 attack when the client did indeed reach a TLS 1.3 server, provided 290 ephemeral ciphers are being used. 292 From a network security point of view, the primary impact is that TLS 293 1.3 requires the TLS proxy to be an active man-in-the-middle from the 294 start of the handshake. It is also required that a TLS 1.2 and below 295 middlebox implementation must handle unsupported extensions 296 gracefully, which is a requirement for a conformant middlebox. 298 2.2.4. SNI Encryption in TLS Through Tunneling 300 As noted above, with server certificates encrypted, the Server Name 301 Indication (SNI) in the ClientHello message is the only information 302 available in cleartext to indicate the client's targeted server, and 303 the actual server reached may differ. 305 [I-D.ietf-tls-sni-encryption] proposes to hide the SNI in the 306 ClientHello from middleboxes. 308 Example scenarios that are impacted by this involve selective network 309 security, such as whitelists or blacklists based on security 310 intelligence, regulatory requirements, categories (e.g. financial 311 services), etc. An added challenge is that some of these scenarios 312 require the middlebox to perform inspection, whereas other scenarios 313 require the middlebox to not perform inspection, however without the 314 SNI, the middlebox may not have the information required to determine 315 the actual scenario before it is too late. 317 3. Inbound Session Use Cases 319 In this section we explain how a set of inbound real-life inbound use 320 case scenarios are affected by some of the TLS 1.3 changes. 322 3.1. Use Case I1 - Data Center Protection 324 Services deployed in the data center may be offered for access by 325 external and untrusted hosts. Network security functions such as IPS 326 and Web Application Firewall (WAF) are deployed to monitor and 327 control the transactions to these services. While an Application 328 level load balancer is not a security function strictly speaking, it 329 is also an important function that resides in front of these services 331 These network security functions are usually deployed in two modes: 332 monitoring and inline. In either case, they need to access the L7 333 and application data such as HTTP transactions which could be 334 protected by TLS encryption. They may monitor the TLS handshakes for 335 additional visibility and control. 337 The TLS handshake monitoring function will be impacted by TLS 1.3. 339 For additional considerations on this scenario, see also 340 [I-D.green-tls-static-dh-in-tls13]. 342 3.2. Use Case I2 - Application Operation over NAT 344 The Network Address Translation (NAT) function translates L3 and L4 345 addresses and ports as the packet traverses the network device. 346 Sophisticated NAT devices may also implement application inspection 347 engines to correct L3/L4 data embedded in the control messages (e.g., 348 FTP control message, SIP signaling messages) so that they are 349 consistent with the outer L3/L4 headers. 351 Without the correction, the secondary data (FTP) or media (SIP) 352 connections will likely reach a wrong destination. 354 The embedded address and port correction operation requires access to 355 the L7 payload which could be protected by encryption. 357 3.3. Use Case I3 - Compliance 359 Many regulations exist today that include cyber security requirements 360 requiring close inspection of the information traversing through the 361 network. For example, organizations that require PCI-DSS [PCI-DSS] 362 compliance must provide the ability to regularly monitor the network 363 to prevent, detect and minimize impact of a data compromise. 364 [PCI-DSS] Requirement #2 (and Appendix A2 as it concerns TLS) 365 describes the need to be able to detect protocol and protocol usage 366 correctness. Further, [PCI-DSS] Requirement #10 detailing monitoring 367 capabilities also describe the need to provide network-based audit to 368 ensure that the protocols and configurations are properly used. 370 Deployments today still use factory or default credentials and 371 settings that must be observed, and to meet regulatory compliance, 372 must be audited, logged and reported. As the server (certificate) 373 credential is now encrypted in TLS 1.3, the ability to verify the 374 appropriate (or compliant) use of these credentials are lost, unless 375 the middlebox always becomes an active MITM. 377 3.4. Use Case I4 - Crypto Security Audit 379 Organizations may have policies around acceptable ciphers and 380 certificates on their servers. Examples include no use of self- 381 signed certificates, black or white-list Certificate Authority, etc. 382 In TLS 1.2, the Certificate message was sent in clear-text, however 383 in TLS 1.3 the message is encrypted thereby preventing either a 384 network-based audit or policy enforcement around acceptable server 385 certificates. 387 While the audits and policy enforcements could in theory be done on 388 the servers themselves, the premise of the use case is that not all 389 servers are configured correctly and hence such an approach is 390 unlikely to work in practice. A common example where this occurs 391 includes lab servers. 393 4. Outbound Session Use Cases 395 In this section we explain a set of real-life outbound session use 396 case scenarios. These scenarios remain functional with TLS 1.3 397 though the TLS proxy's performance is impacted by participating in 398 the DHE key exchange from the beginning of the handshake. 400 4.1. Use Case O1 - Acceptable Use Policy (AUP) 402 Enterprises deploy security devices to enforce Acceptable Use Policy 403 (AUP) according to the IT and workplace policies. The security 404 devices, such as firewall/next-gen firewall, web proxy and an 405 application on the endpoints, act as middleboxes to scan traffic in 406 the enterprise network for policy enforcement. 408 Sample AUP policies are: 410 o "Employees are not allowed to access 'gaming' websites from 411 enterprise network" 413 o "Temporary workers are not allowed to use enterprise network to 414 upload video clips to Internet, but are allowed to watch video 415 clips" 417 Such enforcements are accomplished by controlling the DNS 418 transactions and HTTP transactions. A coarse control is achieved by 419 controlling the DNS response (which itself may be protected by TLS), 420 however, in many cases, granular control is required at HTTP URL or 421 Method levels, to distinguish a specific web page on a hosting site, 422 or to differentiate between uploading and downloading operations. 424 The security device requires access to plain text HTTP header for 425 granular AUP control. 427 4.2. Use Case O2 - Malware and Threat Protection 429 Enterprises adopt a multi-technology approach when it comes to 430 malware and threat protection for the network assets. This includes 431 solutions deployed on the endpoint, network and cloud. 433 While an endpoint application based solution may be effective in 434 protecting from malware and virus attacks, enterprises prefer to 435 deploy multiple technologies for a multi-layer protection. Network 436 based solutions provide such additional protection with the benefit 437 of rapid and centralized updates. 439 The network based solutions comprise security devices and 440 applications that scan network traffic for the purpose from malware 441 signatures to 0-day analysis. 443 The security functions require access to clear text HTTP or other 444 application level streams on a needed basis. 446 4.3. Use Case O3 - IoT Endpoints 448 As the Internet of Everything continues to evolve, more and more 449 endpoints become connected to the Internet. From a security point of 450 view, some of the challenges presented by these are: 452 o Constrained devices with limited resources (CPU, memory, etc.) 454 o Lack of ability to install and update endpoint protection 455 software. 457 o Lack of software updates as new vulnerabilities are discovered. 459 In short, the security posture of such devices is expected to be 460 weak, especially as they get older, and the only way to improve this 461 posture is to supplement them with a network-based solution. This in 462 turn requires a MITM. 464 4.4. Use Case O4 - Unpatched Endpoints 466 New vulnerabilities appear constantly and in spite of many advances 467 in recent years in terms of automated software updates, especially in 468 reaction to security vulnerabilities, the reality is that a very 469 large number of endpoints continue to run versions of software with 470 known vulnerabilities. 472 In theory, these endpoints should of course be patched, but in 473 practice, it is often not done which leaves the endpoint open to the 474 vulnerability in question. A network-based security solution can 475 look for attempted exploits of such vulnerabilities and stop them 476 before they reach the unpatched endpoint. 478 4.5. Use Case O5 - Rapid Containment of New Vulnerability and Campaigns 480 When a new vulnerability is discovered or an attack campaign is 481 launched, it is important to patch the vulnerability or contain the 482 campaign as quickly as possible. Patches however are not always 483 available immediately, and even when they are, most endpoints are in 484 practice not patched immediately, which leaves them open to the 485 attack. 487 A network-based security solution can look for attempted exploits of 488 such new vulnerabilities or recognize an attack being launched based 489 on security intelligence related to the campaign and stop them before 490 they reach the vulnerable endpoint. 492 4.6. Use Case O6 - End-of-Life Endpoint 494 Older endpoints (and in some cases even new ones) will not receive 495 any software updates. As new vulnerabilities inevitably are 496 discovered, these endpoints will be vulnerable to exploits. 498 A network-based security solution can help prevent such exploits with 499 the MITM functions. 501 4.7. Use Case O7 - Compliance 503 This use case is similar to the inbound compliance use case described 504 in Section 3.3, except its from the client point of view. 506 4.8. Use Case O8 - Crypto Security Audit 508 This is a variation of the use case in Section 3.4. 510 Organizations may have policies around acceptable ciphers and 511 certificates for client sessions, possibly based on the destination. 512 Examples include no use of self-signed certificates, black or white- 513 list Certificate Authority, etc. In TLS 1.2, the Certificate message 514 was sent in clear-text, however in TLS 1.3 the message is encrypted 515 thereby preventing either a network-based audit or policy enforcement 516 around acceptable server certificates. 518 While the audits and policy enforcements could in theory be done on 519 the clients themselves, not all clients are configured correctly and 520 may not even be directly under configuration control of the 521 organization in question (e.g. due to Bring Your Own Device). 523 5. IANA considerations 525 This document does not include IANA considerations. 527 6. Security Considerations 529 This document describes existing functionality and use case scenarios 530 and as such does not introduce any new security considerations. 532 7. Acknowledgements 534 Eric Rescorla provided several comments on technical accuracy and 535 middlebox security implications. 537 8. Change Log 539 8.1. Version -01 541 Updates based on comments from Eric Rescorla. 543 9. References 545 9.1. Normative References 547 [I-D.ietf-tls-tls13] 548 Rescorla, E., "The Transport Layer Security (TLS) Protocol 549 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 550 March 2018. 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 558 (TLS) Protocol Version 1.2", RFC 5246, 559 DOI 10.17487/RFC5246, August 2008, 560 . 562 9.2. Informative References 564 [HTTPSintercept] 565 "The Security Impact of HTTPS Interception", n.d., 566 . 568 [I-D.green-tls-static-dh-in-tls13] 569 Green, M., Droms, R., Housley, R., Turner, P., and S. 570 Fenter, "Data Center use of Static Diffie-Hellman in TLS 571 1.3", draft-green-tls-static-dh-in-tls13-01 (work in 572 progress), July 2017. 574 [I-D.ietf-tls-sni-encryption] 575 Huitema, C. and E. Rescorla, "Issues and Requirements for 576 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03 577 (work in progress), May 2018. 579 [NERCCIP] "North American Electric Reliability Corporation, (CIP) 580 Critical Infrastructure Protection", n.d., 581 . 584 [PCI-DSS] "Payment Card Industry (PCI): Data Security Standard", 585 n.d., . 588 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 589 "Transport Layer Security (TLS) Session Resumption without 590 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 591 January 2008, . 593 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 594 Langley, A., and M. Ray, "Transport Layer Security (TLS) 595 Session Hash and Extended Master Secret Extension", 596 RFC 7627, DOI 10.17487/RFC7627, September 2015, 597 . 599 Authors' Addresses 601 Flemming Andreasen 602 Cisco Systems 603 111 Wood Avenue South 604 Iselin, NJ 08830 605 USA 607 Email: fandreas@cisco.com 608 Nancy Cam-Winget 609 Cisco Systems 610 3550 Cisco Way 611 San Jose, CA 95134 612 USA 614 Email: ncamwing@cisco.com 616 Eric Wang 617 Cisco Systems 618 3550 Cisco Way 619 San Jose, CA 95134 620 USA 622 Email: ejwang@cisco.com