--- 1/draft-ietf-opsec-ns-impact-03.txt 2021-01-26 12:13:10.837386371 -0800 +++ 2/draft-ietf-opsec-ns-impact-04.txt 2021-01-26 12:13:10.873387316 -0800 @@ -1,22 +1,22 @@ OPSEC Working Group N. Cam-Winget Internet-Draft E. Wang Intended status: Informational Cisco Systems, Inc. -Expires: April 28, 2021 R. Danyliw +Expires: July 30, 2021 R. Danyliw Software Engineering Institute R. DuToit Broadcom - October 25, 2020 + January 26, 2021 Impact of TLS 1.3 to Operational Network Security Practices - draft-ietf-opsec-ns-impact-03 + draft-ietf-opsec-ns-impact-04 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,25 +29,25 @@ 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 April 28, 2021. + This Internet-Draft will expire on July 30, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 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 @@ -120,34 +120,38 @@ o enforce policy on a system even if it is compromised, misconfigured, not under configuration control or had its endpoint protection disabled o be managed (e.g. updates) and provisioned with resources (e.g. disk and computing) independent of the systems it is protecting o by itself, a single system may not be able to detect and mitigate 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]. 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]. + Security architectures must evolve in response to the adoption of new + technologies, protocols and threats to remain effective. [RFC8404] + documented such an evolution in the context of the adoption of + pervasive encryption. Taking a narrowing focus, this document + enumerates existing network-based security practices that enforce + policy on; or are used to detect or mitigate threats in TLS 1.2 + [RFC5246] (and earlier) traffic. This document is not a complete + survey of these practices or a comprehensive migration guide to TLS + 1.3. + + In response to pervasive monitoring practices [RFC7258], TLS 1.3 + [RFC8446] explicitly engineered for improved security and privacy + properties (see Section 4). In order to aid operators with adoption, + this document describes the impact of TLS 1.3 on these existing + network security practices and highlights areas where security + architectures will require evolution. + + The document is not intended to endorse the use of TLS inspection. 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 @@ -642,23 +645,22 @@ traffic traversing a NAT boundary. While not strictly a security function, this capability may typically be found in firewalls along with the NAT supporting functions. TLS 1.3 considerations: no impact. 6. Security Considerations This document presents common and existing security monitoring and detection functionality and how it interacts with TLS. It further - notes where existing practices will have to be adjusted to remain - effective as these solutions transition to include TLS 1.3 - improvements. + notes where existing practices will have to evolve as TLS 1.3 is + adopted. These operational practices involve both good faith and malicious client applications. The former category typically exhibits consistently identifiable behavior and does not actively prevent any transit inspection devices from performing application identification for visibility and control purposes. The latter category of applications actively attempts to circumvent network security controls by deliberately manipulating various protocol headers, injecting specific messages, and varying payload sizes in order to avoid identification or to masquerade as a different permitted @@ -730,20 +732,24 @@ [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS Encrypted Client Hello", draft-ietf-tls-esni-07 (work in progress), June 2020. [NONCE_FAIL] Jovanovic, P., "Nonce-disrespecting adversaries: Practical forgery attacks on GCM in TLS", 2016, . + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, . + [TLS_VULNERABILITY] Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in the Wild", 2017, . [WEAK_K2] Heninger, N., "Weak Keys Remain Widespread in Network Devices", 2016, . [WEAK_KEY]