--- 1/draft-ietf-opsec-ns-impact-02.txt 2020-10-25 19:13:25.366320653 -0700 +++ 2/draft-ietf-opsec-ns-impact-03.txt 2020-10-25 19:13:25.402321559 -0700 @@ -1,22 +1,22 @@ OPSEC Working Group N. Cam-Winget Internet-Draft E. Wang Intended status: Informational Cisco Systems, Inc. -Expires: January 29, 2021 R. Danyliw +Expires: April 28, 2021 R. Danyliw Software Engineering Institute R. DuToit Broadcom - July 28, 2020 + October 25, 2020 Impact of TLS 1.3 to Operational Network Security Practices - draft-ietf-opsec-ns-impact-02 + draft-ietf-opsec-ns-impact-03 Abstract Network-based security solutions are used by enterprises, the public sector, internet-service providers, and cloud-service providers to both complement and enhance host-based security solutions. As TLS is a widely deployed protocol to secure communication, these network- based security solutions must necessarily interact with it. This document describes this interaction for current operational security practices and notes the impact of TLS 1.3 on them. @@ -29,77 +29,77 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 29, 2021. + This Internet-Draft will expire on April 28, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 + 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. How TLS is used to enable Network-Based Security Solutions . 4 4. Changes in TLS 1.3 Relevant to Security Operations . . . . . 5 4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 5 4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 5 5. Network Security Operational Practices . . . . . . . . . . . 6 - 5.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 6 + 5.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 7 5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via header inspection). . . . . . . . . . . . . . . . . . 7 - 5.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 7 + 5.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 8 5.1.3. OP-3. Crypto, Security and Security Policy Compliance (server) . . . . . . . . . . . . . . . . . 8 5.1.4. OP-4. Crypto and Security Policy Compliance (client) 8 5.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 9 5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via payload inspection) . . . . . . . . . . . . . . . . . 10 5.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 10 - 5.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 10 - 5.2.4. OP-8: Network-based Threat Protection (client) . . . 10 + 5.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 11 + 5.2.4. OP-8: Network-based Threat Protection (client) . . . 11 5.2.5. OP-9: Protecting Challenging End Points . . . . . . . 11 - 5.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 11 - 5.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 11 - 5.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 12 + 5.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 12 + 5.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 12 + 5.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 13 5.3.2. OP-12. Content distribution and application load balancing . . . . . . . . . . . . . . . . . . . . . . 13 - 5.3.3. OP-13: Network-based Threat Protection (server) . . . 13 - 5.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 13 + 5.3.3. OP-13: Network-based Threat Protection (server) . . . 14 + 5.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 14 5.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 14 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Appendix A: Summary Impact to Operational Practices with TLS - 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Enterprises, public sector organizations, internet service providers and cloud service providers defend their networks and information systems from attacks that originate from inside and outside their networks. These organizations commonly employ security architectures that involve complementary technologies deployed on both endpoints and in the network; and collaborative watch-and-warning practices to realize this defense. @@ -128,44 +128,53 @@ threats In response to the adoption of new technologies, protocols and threats, these security architectures must evolve to remain effective. [RFC8404] documented a need to evolve with the effect of pervasive encryption on operations. This document takes a narrower focus by documenting the interaction of existing network-based security practices with TLS 1.2 [RFC5246] (and earlier) traffic to implement security policy, detection or mitigation of threats; and the impact on these practices with improvements made in TLS 1.3 - [RFC8446]. + [RFC8446]. The document is not intended to endorse the use of TLS + inspection, rather it describes current practice and its implications + as observed at the time of this writing to help the IETF community + understand the perspective of network operators. The goal is to help + further the need to evolve such solutions as protocols evolve, in + particular TLS [RFC8446]. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Specific operational practices are numbered as "OP-##", operational practice 1 (i.e., OP-1), 2 (i.e., OP-2), etc. 3. How TLS is used to enable Network-Based Security Solutions Network-based security solutions come in many forms, most commonly as Firewalls, Web Proxies, Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) and Network Security Visibility and Analytics systems. They inspect the network traffic, and then based on their function, log their observation and/or act on the traffic to - implement security policy. When these devices act on the network - traffic, they are typically deployed inline as middleboxes (e.g. - firewalls) or as explicit proxies (e.g. web proxies). If their - function is only to observe, they can be deployed either as + implement security policy. The conditions under which TLS visibility + is required is specific to the network security vendor and deployment + and out of scope for this document but the use of visibility and + inspection are common and described herein. When these devices act + on the network traffic, they are typically deployed inline as + middleboxes (e.g. firewalls) or as explicit proxies (e.g. web + proxies). + If their function is only to observe, they can be deployed either as middleboxes or given access to the network traffic out-of-band (OOB), through the network fabric (e.g., network tap or span port). Depending on their function, network-based security devices use different degrees of visibility into the TLS traffic. Some operational practices require only access to the unencrypted protocol headers and associated meta-data of the TLS traffic. Other practices require full visibility into the encrypted session (payload). The practices that inspect only the unencrypted headers and meta-data @@ -206,21 +215,21 @@ TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman (DH) cipher suites, which enables the server's private key to be shared with a TLS proxy. [RFC7525] initiated the recommendation of using AEAD cipher suites and specifically decoupling the cipher suite negotiation based on the RSA key transport; this followed with TLS 1.3 explicitly removing support for these cipher suites in favor of supporting only ephemeral mode Diffie-Hellman to provide perfect forward secrecy (PFS). As a result of this enhancement, it would no longer be possible for a server to share a key with the middlebox in advance, which in turn implies that the middlebox cannot gain access - to the TLS session data.ss + to the TLS session data. 4.2. Encrypted Server Certificate TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and Certificate messages in clear-text. In TLS 1.3, the Certificate message is encrypted whereby hiding the server identity from any intermediary. As a result of this enhancement, it would no longer be possible to observe the server certificate without inspection the encrypted TLS payload.