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/