draft-ietf-opsec-ns-impact-03.txt   draft-ietf-opsec-ns-impact-04.txt 
OPSEC Working Group N. Cam-Winget OPSEC Working Group N. Cam-Winget
Internet-Draft E. Wang Internet-Draft E. Wang
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: April 28, 2021 R. Danyliw Expires: July 30, 2021 R. Danyliw
Software Engineering Institute Software Engineering Institute
R. DuToit R. DuToit
Broadcom Broadcom
October 25, 2020 January 26, 2021
Impact of TLS 1.3 to Operational Network Security Practices Impact of TLS 1.3 to Operational Network Security Practices
draft-ietf-opsec-ns-impact-03 draft-ietf-opsec-ns-impact-04
Abstract Abstract
Network-based security solutions are used by enterprises, the public Network-based security solutions are used by enterprises, the public
sector, internet-service providers, and cloud-service providers to sector, internet-service providers, and cloud-service providers to
both complement and enhance host-based security solutions. As TLS is both complement and enhance host-based security solutions. As TLS is
a widely deployed protocol to secure communication, these network- a widely deployed protocol to secure communication, these network-
based security solutions must necessarily interact with it. This based security solutions must necessarily interact with it. This
document describes this interaction for current operational security document describes this interaction for current operational security
practices and notes the impact of TLS 1.3 on them. practices and notes the impact of TLS 1.3 on them.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 38 skipping to change at page 3, line 38
o enforce policy on a system even if it is compromised, o enforce policy on a system even if it is compromised,
misconfigured, not under configuration control or had its endpoint misconfigured, not under configuration control or had its endpoint
protection disabled protection disabled
o be managed (e.g. updates) and provisioned with resources (e.g. o be managed (e.g. updates) and provisioned with resources (e.g.
disk and computing) independent of the systems it is protecting disk and computing) independent of the systems it is protecting
o by itself, a single system may not be able to detect and mitigate o by itself, a single system may not be able to detect and mitigate
threats threats
In response to the adoption of new technologies, protocols and Security architectures must evolve in response to the adoption of new
threats, these security architectures must evolve to remain technologies, protocols and threats to remain effective. [RFC8404]
effective. [RFC8404] documented a need to evolve with the effect of documented such an evolution in the context of the adoption of
pervasive encryption on operations. This document takes a narrower pervasive encryption. Taking a narrowing focus, this document
focus by documenting the interaction of existing network-based enumerates existing network-based security practices that enforce
security practices with TLS 1.2 [RFC5246] (and earlier) traffic to policy on; or are used to detect or mitigate threats in TLS 1.2
implement security policy, detection or mitigation of threats; and [RFC5246] (and earlier) traffic. This document is not a complete
the impact on these practices with improvements made in TLS 1.3 survey of these practices or a comprehensive migration guide to TLS
[RFC8446]. The document is not intended to endorse the use of TLS 1.3.
inspection, rather it describes current practice and its implications
as observed at the time of this writing to help the IETF community In response to pervasive monitoring practices [RFC7258], TLS 1.3
understand the perspective of network operators. The goal is to help [RFC8446] explicitly engineered for improved security and privacy
further the need to evolve such solutions as protocols evolve, in properties (see Section 4). In order to aid operators with adoption,
particular TLS [RFC8446]. 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 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Specific operational practices are numbered as "OP-##", operational Specific operational practices are numbered as "OP-##", operational
skipping to change at page 15, line 11 skipping to change at page 15, line 11
traffic traversing a NAT boundary. While not strictly a security traffic traversing a NAT boundary. While not strictly a security
function, this capability may typically be found in firewalls along function, this capability may typically be found in firewalls along
with the NAT supporting functions. with the NAT supporting functions.
TLS 1.3 considerations: no impact. TLS 1.3 considerations: no impact.
6. Security Considerations 6. Security Considerations
This document presents common and existing security monitoring and This document presents common and existing security monitoring and
detection functionality and how it interacts with TLS. It further detection functionality and how it interacts with TLS. It further
notes where existing practices will have to be adjusted to remain notes where existing practices will have to evolve as TLS 1.3 is
effective as these solutions transition to include TLS 1.3 adopted.
improvements.
These operational practices involve both good faith and malicious These operational practices involve both good faith and malicious
client applications. The former category typically exhibits client applications. The former category typically exhibits
consistently identifiable behavior and does not actively prevent any consistently identifiable behavior and does not actively prevent any
transit inspection devices from performing application identification transit inspection devices from performing application identification
for visibility and control purposes. The latter category of for visibility and control purposes. The latter category of
applications actively attempts to circumvent network security applications actively attempts to circumvent network security
controls by deliberately manipulating various protocol headers, controls by deliberately manipulating various protocol headers,
injecting specific messages, and varying payload sizes in order to injecting specific messages, and varying payload sizes in order to
avoid identification or to masquerade as a different permitted avoid identification or to masquerade as a different permitted
skipping to change at page 17, line 5 skipping to change at page 16, line 50
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-07 (work in Encrypted Client Hello", draft-ietf-tls-esni-07 (work in
progress), June 2020. progress), June 2020.
[NONCE_FAIL] [NONCE_FAIL]
Jovanovic, P., "Nonce-disrespecting adversaries: Practical Jovanovic, P., "Nonce-disrespecting adversaries: Practical
forgery attacks on GCM in TLS", 2016, forgery attacks on GCM in TLS", 2016,
<https://www.usenix.org/conference/woot16/workshop- <https://www.usenix.org/conference/woot16/workshop-
program/presentation/bock>. program/presentation/bock>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[TLS_VULNERABILITY] [TLS_VULNERABILITY]
Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in
the Wild", 2017, the Wild", 2017,
<https://rwc.iacr.org/2017/Slides/david.mcgrew.pptx>. <https://rwc.iacr.org/2017/Slides/david.mcgrew.pptx>.
[WEAK_K2] Heninger, N., "Weak Keys Remain Widespread in Network [WEAK_K2] Heninger, N., "Weak Keys Remain Widespread in Network
Devices", 2016, <https://www.cis.upenn.edu/~nadiah/papers/ Devices", 2016, <https://www.cis.upenn.edu/~nadiah/papers/
weak-keys/weak-keys.pdf>. weak-keys/weak-keys.pdf>.
[WEAK_KEY] [WEAK_KEY]
 End of changes. 8 change blocks. 
22 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/