draft-ietf-taps-transport-security-09.txt		draft-ietf-taps-transport-security-10.txt
	Network Working Group C. Wood, Ed.		Network Working Group T. Enghardt
	Internet-Draft Apple Inc.		Internet-Draft TU Berlin
	Intended status: Informational T. Enghardt		Intended status: Informational T. Pauly
	Expires: March 31, 2020 TU Berlin		Expires: May 21, 2020 Apple Inc.
	T. Pauly
	Apple Inc.
	C. Perkins		C. Perkins
	University of Glasgow		University of Glasgow
	K. Rose		K. Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	September 28, 2019		C. Wood, Ed.
			Apple Inc.
			November 18, 2019
	A Survey of Transport Security Protocols		A Survey of the Interaction Between Security Protocols and Transport
	draft-ietf-taps-transport-security-09		Services
			draft-ietf-taps-transport-security-10
	Abstract		Abstract
	This document provides a survey of commonly used or notable network		This document provides a survey of commonly used or notable network
	security protocols, with a focus on how they interact and integrate		security protocols, with a focus on how they interact and integrate
	with applications and transport protocols. Its goal is to supplement		with applications and transport protocols. Its goal is to supplement
	efforts to define and catalog transport services by describing the		efforts to define and catalog transport services by describing the
	interfaces required to add security protocols. This survey is not		interfaces required to add security protocols. This survey is not
	limited to protocols developed within the scope or context of the		limited to protocols developed within the scope or context of the
	IETF, and those included represent a superset of features a Transport		IETF, and those included represent a superset of features a Transport
	Services system may need to support. Moreover, this document defines		Services system may need to support.
	a minimal set of security features that a secure transport system
	should provide.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 31, 2020.		This Internet-Draft will expire on May 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
			1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
			1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Security Features . . . . . . . . . . . . . . . . . . . . . . 6		3. Transport Security Protocol Descriptions . . . . . . . . . . 6
	4. Transport Security Protocol Descriptions . . . . . . . . . . 7		3.1. Application Payload Security Protocols . . . . . . . . . 6
	4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.1. Protocol Description . . . . . . . . . . . . . . . . 8		3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1.2. Security Features . . . . . . . . . . . . . . . . . . 9		3.2. Application-Specific Security Protocols . . . . . . . . . 6
	4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9		3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 6
	4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2.2. ZRTP for Media Path Key Agreement . . . . . . . . . . 7
	4.2.1. Protocol Description . . . . . . . . . . . . . . . . 10		3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7
	4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10		3.3.1. QUIC with TLS . . . . . . . . . . . . . . . . . . . . 7
	4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10		3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 7
	4.3. QUIC with TLS . . . . . . . . . . . . . . . . . . . . . . 11		3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11		3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.2. Security Features . . . . . . . . . . . . . . . . . . 12		3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12		3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 8
	4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12		3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 8
	4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12		3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 8
	4.4.1. IKEv2 Protocol Description . . . . . . . . . . . . . 12		3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4.2. ESP Protocol Description . . . . . . . . . . . . . . 13		4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9
	4.4.3. IKEv2 Security Features . . . . . . . . . . . . . . . 14		4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 9
	4.4.4. ESP Security Features . . . . . . . . . . . . . . . . 14		4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 9
	4.4.5. IKEv2 Protocol Dependencies . . . . . . . . . . . . . 14		4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 10
	4.4.6. ESP Protocol Dependencies . . . . . . . . . . . . . . 15		4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 10
	4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15		5. Application Interface . . . . . . . . . . . . . . . . . . . . 10
	4.5.1. Protocol description . . . . . . . . . . . . . . . . 15		5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 11
	4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16		5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 13
	4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16		5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 13
	4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 17		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
	4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18		10. Informative References . . . . . . . . . . . . . . . . . . . 15
	4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	4.7.1. Protocol description . . . . . . . . . . . . . . . . 19
	4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
	4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20
	4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
	4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21
	4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21
	4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 22
	4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22
	4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 23
	4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23
	4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23
	4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23
	4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24
	4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 25
	5. Security Features and Application Dependencies . . . . . . . 25
	5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25
	5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 26
	5.3. Optional Feature Availability . . . . . . . . . . . . . . 27
	6. Transport Security Protocol Interfaces . . . . . . . . . . . 29
	6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29
	6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30
	6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	11. Informative References . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	Services and features provided by transport protocols have been		Services and features provided by transport protocols have been
	cataloged in [RFC8095]. This document supplements that work by		cataloged in [RFC8095]. This document supplements that work by
	surveying commonly used and notable network security protocols, and		surveying commonly used and notable network security protocols, and
	identifying the services and features a Transport Services system (a		identifying the services and features a Transport Services system (a
	system that provides a transport API) needs to provide in order to		system that provides a transport API) needs to provide in order to
	add transport security. It examines Transport Layer Security (TLS),		add transport security. It examines Transport Layer Security (TLS),
	Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt,		Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt,
	Internet Key Exchange with Encapsulating Security Protocol (IKEv2 +		Internet Key Exchange with Encapsulating Security Protocol (IKEv2 +
	ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each		ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each
	protocol, this document provides a brief description, the security		protocol, this document provides a brief description, the
	features it provides, and the dependencies it has on the underlying		dependencies it has on the underlying transports, and the interfaces
	transport. This is followed by defining the set of transport		provided to applications.
	security features shared by these protocols. The document groups
	these security features into a minimal set of features, which every
	secure transport system should provide in addition to the transport
	features described in [I-D.ietf-taps-minset], and additional optional
	features, which may not be available in every secure transport
	system. Finally, the document distills the application and transport
	interfaces provided by the transport security protocols.
	Selected protocols represent a superset of functionality and features		Selected protocols represent a superset of functionality and features
	a Transport Services system may need to support, both internally and		a Transport Services system may need to support, both internally and
	externally (via an API) for applications [I-D.ietf-taps-arch].		externally (via an API) for applications [I-D.ietf-taps-arch].
	Ubiquitous IETF protocols such as (D)TLS, as well as non-standard		Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
	protocols such as Google QUIC, are both included despite overlapping		protocols such as Google QUIC, are both included despite overlapping
	features. As such, this survey is not limited to protocols developed		features. As such, this survey is not limited to protocols developed
	within the scope or context of the IETF. Outside of this candidate		within the scope or context of the IETF. Outside of this candidate
	set, protocols that do not offer new features are omitted. For		set, protocols that do not offer new features are omitted. For
	example, newer protocols such as WireGuard make unique design choices		example, newer protocols such as WireGuard make unique design choices
	that have important implications on applications, such as how to best		that have implications and limitations on application usage. In
	configure peer public keys and to delegate algorithm selection to the		contrast, protocols such as ALTS [ALTS] are omitted since they do not
	system. In contrast, protocols such as ALTS [ALTS] are omitted since		provide interfaces deemed unique.
	they do not represent features deemed unique.
	Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH		Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH
	[RFC4302] are excluded from this survey. TCP-AO adds authenticity		[RFC4302] are excluded from this survey. TCP-AO adds authenticity
	protections to long-lived TCP connections, e.g., replay protection		protections to long-lived TCP connections, e.g., replay protection
	with per-packet Message Authentication Codes. (This protocol		with per-packet Message Authentication Codes. (This protocol
	obsoletes TCP MD5 "signature" options specified in [RFC2385].) One		obsoletes TCP MD5 "signature" options specified in [RFC2385].) One
	prime use case of TCP-AO is for protecting BGP connections.		prime use case of TCP-AO is for protecting BGP connections.
	Similarly, AH adds per-datagram authenticity and adds similar replay		Similarly, AH adds per-datagram authenticity and adds similar replay
	protection. Despite these improvements, neither protocol sees		protection. Despite these improvements, neither protocol sees
	general use and both lack critical properties important for emergent		general use and both lack critical properties important for emergent
	transport security protocols: confidentiality, privacy protections,		transport security protocols: confidentiality, privacy protections,
	and agility. Such protocols are thus omitted from this survey.		and agility. Such protocols are thus omitted from this survey.
			1.1. Goals
			This survey is intended to help identify the most common interface
			surfaces between security protocols and transport protocols, and
			between security protocols and applications.
			One of the goals of Transport Services is to define a common
			interface for using transport protocols that allows software using
			transport protocols to easily adopt new protocols that provide
			similar feature-sets. The survey of the dependencies security
			protocols have upon transport protocols can guide implementations in
			determining which transport protocols are appropriate to be able to
			use beneath a given security protocol. For example, a security
			protocol that expects to run over a reliable stream of bytes, like
			TLS, restrict the set of transport protocols that can be used to
			those that offer a reliable stream of bytes.
			Defining the common interfaces that security protocols provide to
			applications also allows interfaces to be designed in a way that
			common functionality can use the same APIs. For example, many
			security protocols that provide authentication let the application be
			involved in peer identity validation. Any interface to use a secure
			transport protocol stack thus needs to allow applications to perform
			this action during connection establishment.
			1.2. Non-Goals
			While this survey provides similar analysis to that which was
			performed for transport protocols in [RFC8095], it is important to
			distinguish that the use of security protocols requires more
			consideration.
			It is not a goal to allow software implementations to automatically
			switch between different security protocols, even where their
			interfaces to transport and applications are equivalent. Even
			between versions, security protocols have subtly different guarantees
			and vulnerabilities. Thus, any implementation needs to only use the
			set of protocols and algorithms that are requested by applications or
			by a system policy.
	2. Terminology		2. Terminology
	The following terms are used throughout this document to describe the		The following terms are used throughout this document to describe the
	roles and interactions of transport security protocols:		roles and interactions of transport security protocols:
	o Transport Feature: a specific end-to-end feature that the		o Transport Feature: a specific end-to-end feature that the
	transport layer provides to an application. Examples include		transport layer provides to an application. Examples include
	confidentiality, reliable delivery, ordered delivery, message-		confidentiality, reliable delivery, ordered delivery, message-
	versus-stream orientation, etc.		versus-stream orientation, etc.
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 19 ¶
	functionality to an application.		functionality to an application.
	o Transport Protocol: an implementation that provides one or more		o Transport Protocol: an implementation that provides one or more
	different transport services using a specific framing and header		different transport services using a specific framing and header
	format on the wire. A Transport Protocol services an application.		format on the wire. A Transport Protocol services an application.
	o Application: an entity that uses a transport protocol for end-to-		o Application: an entity that uses a transport protocol for end-to-
	end delivery of data across the network. This may also be an		end delivery of data across the network. This may also be an
	upper layer protocol or tunnel encapsulation.		upper layer protocol or tunnel encapsulation.
	o Security Feature: a feature that a network security layer provides
	to applications. Examples include authentication, encryption, key
	generation, session resumption, and privacy. Features may be
	Mandatory or Optional for an application's implementation.
	Security Features extend the set of Transport Features described
	in [RFC8095] and provided by Transport Services implementations.
	o Security Protocol: a defined network protocol that implements one		o Security Protocol: a defined network protocol that implements one
	or more security features. Security protocols may be used		or more security features, such as authentication, encryption, key
	alongside transport protocols, and in combination with other		generation, session resumption, and privacy. Security protocols
	security protocols when appropriate.		may be used alongside transport protocols, and in combination with
			other security protocols when appropriate.
	o Handshake Protocol: a protocol that enables peers to validate each		o Handshake Protocol: a protocol that enables peers to validate each
	other and to securely establish shared cryptographic context.		other and to securely establish shared cryptographic context.
	o Record: Framed protocol messages.		o Record: Framed protocol messages.
	o Record Protocol: a security protocol that allows data to be		o Record Protocol: a security protocol that allows data to be
	divided into manageable blocks and protected using shared		divided into manageable blocks and protected using shared
	cryptographic context.		cryptographic context.
	o Session: an ephemeral security association between applications.		o Session: an ephemeral security association between applications.
	o Cryptographic context: a set of cryptographic parameters,
	including but not necessarily limited to keys for encryption,
	authentication, and session resumption, enabling authorized
	parties to a session to communicate securely.
	o Connection: the shared state of two or more endpoints that		o Connection: the shared state of two or more endpoints that
	persists across messages that are transmitted between these		persists across messages that are transmitted between these
	endpoints. A connection is a transient participant of a session,		endpoints. A connection is a transient participant of a session,
	and a session generally lasts between connection instances.		and a session generally lasts between connection instances.
	o Peer: an endpoint application party to a session.		o Peer: an endpoint application party to a session.
	o Client: the peer responsible for initiating a session.		o Client: the peer responsible for initiating a session.
	o Server: the peer responsible for responding to a session		o Server: the peer responsible for responding to a session
	initiation.		initiation.
	3. Security Features		3. Transport Security Protocol Descriptions
	In this section, we enumerate Security Features exposed by protocols
	discussed in the remainder of this document. Protocol security (and
	privacy) properties that are unrelated to the API surface exposed by
	such protocols, such as client or server identity hiding, are not
	listed here as features.
	o Forward-secure session key establishment: Establishing
	cryptographic keys with forward-secure properties.
	o Cryptographic algorithm negotiation: Negotiating support of
	protocol algorithms, including algorithms for encryption, hashing,
	MAC (PRF), and digital signatures.
	o Session caching and management: Managing session state caches used
	for subsequent connections, with the aim of amortizing connection
	establishment costs.
	o Peer authentication: Authenticating peers using generic or
	protocol-specific mechanisms, such as certificates, raw public
	keys, pre-shared keys, or EAP methods.
	o Unilateral responder authentication: Requiring authentication for
	the responder of a connection.
	o Mutual authentication: Establishing connections in which both
	endpoints are authenticated.
	o Application authentication delegation: Delegating to applications
	out-of-band to perform peer authentication.
	o Record (channel or datagram) confidentiality and integrity:
	Encrypting and authenticating application plaintext bytes sent
	between peers over a channel or in individual datagrams.
	o Partial record confidentiality: Encrypting some portion of
	records.
	o Optional record integrity: Optionally authenticating certain
	records.
	o Record replay prevention: Detecting and defending against record
	replays, which can be due to in-network retransmissions.
	o Early data support: Transmitting application data prior to secure
	connection establishment via a handshake. For TLS, this support
	begins with TLS 1.3.
	o Connection mobility: Allowing a connection to be multihomed or
	resilient across network interface or address changes, such as NAT
	rebindings that occur without an endpoint's knowledge. Mobility
	allows cryptographic key material and other state information to
	be reused in the event of a connection change.
	o Application-layer feature negotiation: Securely negotiating
	application-specific functionality. Such features may be
	necessary for further application processing, such as the TLS
	parent connection protocol type via ALPN [RFC7301] or desired
	application identity via SNI [RFC6066].
	o Configuration extensions: Adding protocol features via extensions
	or configuration options. TLS extensions are a primary example of
	this feature.
	o Out-of-order record receipt: Processing of records received out-
	of-order.
	o Source validation (cookie or puzzle based): Validating peers and
	mitigating denial-of-service (DoS) attacks via explicit proof of
	origin (cookies) or work mechanisms (puzzles).
	o Length-hiding padding: Adding padding to records in order to hide
	plaintext message length and mitigate amplification attack
	vectors.
	4. Transport Security Protocol Descriptions		This section contains brief descriptions of the various security
			protocols currently used to protect data being sent over a network.
			The interfaces between these protocols and transports are described
			in Section 4; the interfaces between these protocols and applications
			are described in Section 5.
	This section contains descriptions of security protocols currently		3.1. Application Payload Security Protocols
	used to protect data being sent over a network.
	For each protocol, we describe its provided features and dependencies		The following protocols provide security that protects application
	on other protocols.		payloads sent over a transport. They do not specifically protect any
			headers used for transport-layer functionality.
	4.1. TLS		3.1.1. TLS
	TLS (Transport Layer Security) [RFC8446] is a common protocol used to		TLS (Transport Layer Security) [RFC8446] is a common protocol used to
	establish a secure session between two endpoints. Communication over		establish a secure session between two endpoints. Communication over
	this session "prevents eavesdropping, tampering, and message		this session "prevents eavesdropping, tampering, and message
	forgery." TLS consists of a tightly coupled handshake and record		forgery." TLS consists of a tightly coupled handshake and record
	protocol. The handshake protocol is used to authenticate peers,		protocol. The handshake protocol is used to authenticate peers,
	negotiate protocol options, such as cryptographic algorithms, and		negotiate protocol options, such as cryptographic algorithms, and
	derive session-specific keying material. The record protocol is used		derive session-specific keying material. The record protocol is used
	to marshal (possibly encrypted) data from one peer to the other.		to marshal (possibly encrypted) data from one peer to the other.
	This data may contain handshake messages or raw application data.		This data may contain handshake messages or raw application data.
	4.1.1. Protocol Description		3.1.2. DTLS
	TLS is the composition of a handshake and record protocol [RFC8446].
	The record protocol is designed to marshal an arbitrary, in-order
	stream of bytes from one endpoint to the other. It handles
	segmenting, compressing (when enabled), and encrypting data into
	discrete records. When configured to use an authenticated encryption
	with associated data (AEAD) algorithm, it also handles nonce
	generation and encoding for each record. The record protocol is
	hidden from the client behind a bytestream-oriented API.
	The handshake protocol serves several purposes, including: peer
	authentication, protocol option (key exchange algorithm and
	ciphersuite) negotiation, and key derivation. Peer authentication
	may be mutual; however, commonly, only the server is authenticated.
	X.509 certificates are commonly used in this authentication step,
	though other mechanisms, such as raw public keys [RFC7250], exist.
	The client is not authenticated unless explicitly requested by the
	server.
	The handshake protocol is also extensible. It allows for a variety
	of extensions to be included by either the client or server. These
	extensions are used to specify client preferences, e.g., the
	application-layer protocol to be driven with the TLS connection
	[RFC7301], or signals to the server to aid operation, e.g., Server
	Name Indication (SNI) [RFC6066]. Various extensions also exist to
	tune the parameters of the record protocol, e.g., the maximum
	fragment length [RFC6066] and record size limit [RFC8449].
	Alerts are used to convey errors and other atypical events to the
	endpoints. There are two classes of alerts: closure and error
	alerts. A closure alert is used to signal to the other peer that the
	sender wishes to terminate the connection. The sender typically
	follows a close alert with a TCP FIN segment to close the connection.
	Error alerts are used to indicate problems with the handshake or
	individual records. Most errors are fatal and are followed by
	connection termination. However, warning alerts may be handled at
	the discretion of the implementation.
	Once a session is disconnected all session keying material must be
	destroyed, with the exception of secrets previously established
	expressly for purposes of session resumption. TLS supports stateful
	and stateless resumption. (Here, "state" refers to bookkeeping on a
	per-session basis by the server. It is assumed that the client must
	always store some state information in order to resume a session.)
	4.1.2. Security Features
	o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.
	o Stateful and stateless cross-connection session resumption.
	o Session caching and management.
	o Peer authentication (Certificate, raw public key, and pre-shared
	key).
	o Unilateral responder authentication.
	o Mutual authentication.
	o Application authentication delegation.
	o Record (channel) confidentiality and integrity.
	o Record replay prevention.
	o Application-layer feature negotiation.
	o Configuration extensions.
	o Early data support (starting with TLS 1.3).
	o Optional record-layer padding (starting with TLS 1.3).
	4.1.3. Protocol Dependencies
	o In-order, reliable bytestream transport.
	o (Optionally) A PKI trust store for certificate validation.
	4.2. DTLS
	DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,		DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,
	but differs in that it is designed to run over unreliable datagram		but differs in that it is designed to run over unreliable datagram
	protocols like UDP instead of TCP. DTLS modifies the protocol to		protocols like UDP instead of TCP. DTLS modifies the protocol to
	make sure it can still provide the same security guarantees as TLS		make sure it can still provide the same security guarantees as TLS
	even without reliability from the transport. DTLS was designed to be		even without reliability from the transport. DTLS was designed to be
	as similar to TLS as possible, so this document assumes that all		as similar to TLS as possible, so this document assumes that all
	properties from TLS are carried over except where specified.		properties from TLS are carried over except where specified.
	4.2.1. Protocol Description		3.2. Application-Specific Security Protocols
	DTLS is modified from TLS to operate with the possibility of packet
	loss, reordering, and duplication that may occur when operating over
	UDP. To enable out-of-order delivery of application data, the DTLS
	record protocol itself has no inter-record dependencies. However, as
	the handshake requires reliability, each handshake message is
	assigned an explicit sequence number to enable retransmissions of
	lost packets and in-order processing by the receiver. Handshake
	message loss is remedied by sender retransmission after a
	configurable period in which the expected response has not yet been
	received.
	As the DTLS handshake protocol runs atop the record protocol, to
	account for long handshake messages that cannot fit within a single
	record, DTLS supports fragmentation and subsequent reconstruction of
	handshake messages across records. The receiver must reassemble
	records before processing.
	DTLS relies on unique UDP 4-tuples to identify connections, or a
	similar mechanism in other datagram transports. Since all
	application-layer data is encrypted, demultiplexing over the same
	4-tuple requires the use of a connection identifier extension
	[I-D.ietf-tls-dtls-connection-id] to permit identification of the
	correct connection-specific cryptographic context without the use of
	trial decryption. (Note that this extension is only supported in
	DTLS 1.2 and 1.3 [I-D.ietf-tls-dtls13].)
	Since datagrams can be replayed, DTLS provides optional anti-replay
	detection based on a window of acceptable sequence numbers [RFC6347].
	4.2.2. Security Features
	o Record replay protection.
	o Record (datagram) confidentiality and integrity.
	o Out-of-order record receipt.
	o DoS mitigation (cookie-based).
	See also the features from TLS.		The following protocols provide application-specific security by
			protecting application payloads used for specific use-cases. Unlike
			the protocols above, these are not intended for generic application
			use.
	4.2.3. Protocol Dependencies		3.2.1. Secure RTP
	o DTLS relies on an unreliable datagram transport.		Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
			message authentication, and replay protection for RTP data packets
			and RTP control protocol (RTCP) packets [RFC3711].
	o The DTLS record protocol explicitly encodes record lengths, so		3.2.2. ZRTP for Media Path Key Agreement
	although it runs over a datagram transport, it does not rely on
	the transport protocol's framing beyond requiring transport-level
	reconstruction of datagrams fragmented over packets. (Note: DTLS
	1.3 short header records omit the explicit length field.)
	o Uniqueness of the session within the transport flow (only one DTLS		ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
	connection on a UDP 4-tuple, for example); or else support for the		uses standard SRTP to protect RTP data packets and RTCP packets, but
	connection identifier extension to enable demultiplexing.		provides alternative key agreement and identity management protocols.
			Key agreement is performed using a Diffie-Hellman key exchange that
			runs on the media path. This generates a shared secret that is then
			used to generate the master key and salt for SRTP.
	o Path MTU discovery.		3.3. Transport-Layer Security Protocols
	o For the handshake: Reliable, in-order transport. DTLS provides		The following security protocols provide protection for both
	its own reliability.		application payloads and headers that are used for transport
			services.
	4.3. QUIC with TLS		3.3.1. QUIC with TLS
	QUIC is a new standards-track transport protocol that runs over UDP,		QUIC is a new standards-track transport protocol that runs over UDP,
	loosely based on Google's original proprietary gQUIC protocol		loosely based on Google's original proprietary gQUIC protocol
	[I-D.ietf-quic-transport] (See Section 4.3.4 for more details). The		[I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The
	QUIC transport layer itself provides support for data confidentiality		QUIC transport layer itself provides support for data confidentiality
	and integrity. This requires keys to be derived with a separate		and integrity. This requires keys to be derived with a separate
	handshake protocol. A mapping for QUIC of TLS 1.3		handshake protocol. A mapping for QUIC of TLS 1.3
	[I-D.ietf-quic-tls] has been specified to provide this handshake.		[I-D.ietf-quic-tls] has been specified to provide this handshake.
	4.3.1. Protocol Description		3.3.2. Google QUIC
	As QUIC relies on TLS to secure its transport functions, it creates
	specific integration points between its security and transport
	functions:
	o Starting the handshake to generate keys and provide authentication
	(and providing the transport for the handshake).
	o Client address validation.
	o Key ready events from TLS to notify the QUIC transport.
	o Exporting secrets from TLS to the QUIC transport.
	The QUIC transport layer support multiple streams over a single
	connection. QUIC implements a record protocol for TLS handshake
	messages to establish a connection. These messages are sent in
	CRYPTO frames [I-D.ietf-quic-transport] in Initial and Handshake
	packets. Initial packets are encrypted using fixed keys derived from
	the QUIC version and public packet information (Connection ID).
	Handshake packets are encrypted using TLS handshake secrets. Once
	TLS completes, QUIC uses the resulting traffic secrets to for the
	QUIC connection to protect the rest of the frames. QUIC supports
	0-RTT data using previously negotiated connection secrets Early data
	is sent in 0-RTT packets, which may be included in the same datagram
	as the Initial and Handshake packets.
	4.3.2. Security Features
	o DoS mitigation (cookie-based).
	See also the properties of TLS.
	4.3.3. Protocol Dependencies
	o QUIC transport assumes an unreliable transport, e.g., UDP.
	o QUIC transport relies on TLS 1.3 for key exchange, peer
	authentication, and shared secret derivation.
	o For the handshake: Reliable, in-order transport. QUIC provides
	its own reliability.
	4.3.4. Variant: Google QUIC
	Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol		Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
	designed and deployed by Google following experience from deploying		designed and deployed by Google following experience from deploying
	SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally		SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
	known as "QUIC": this document uses gQUIC to unambiguously		known as "QUIC": this document uses gQUIC to unambiguously
	distinguish it from the standards-track IETF QUIC. The proprietary		distinguish it from the standards-track IETF QUIC. The proprietary
	technical forebear of IETF QUIC, gQUIC was originally designed with		technical forebear of IETF QUIC, gQUIC was originally designed with
	tightly-integrated security and application data transport protocols.		tightly-integrated security and application data transport protocols.
	4.4. IKEv2 with ESP		3.3.3. tcpcrypt
	IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
	protocol suite that encrypts and authenticates IP packets, either for
	creating tunnels (tunnel-mode) or for direct transport connections
	(transport-mode). This suite of protocols separates out the key
	generation protocol (IKEv2) from the transport encryption protocol
	(ESP). Each protocol can be used independently, but this document
	considers them together, since that is the most common pattern.
	4.4.1. IKEv2 Protocol Description
	IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and
	TCP port 4500. Its primary goal is to generate keys for Security
	Associations (SAs). An SA contains shared (cryptographic)
	information used for establishing other SAs or keying ESP; See
	Section 4.4.2. IKEv2 first uses a Diffie-Hellman key exchange to
	generate keys for the "IKE SA", which is a set of keys used to
	encrypt further IKEv2 messages. IKE then performs a phase of
	authentication in which both peers present blobs signed by a shared
	secret or private key that authenticates the entire IKE exchange and
	the IKE identities. IKE then derives further sets of keys on demand,
	which together with traffic policies are referred to as the "Child
	SA". These Child SA keys are used by ESP.
	IKEv2 negotiates which protocols are acceptable to each peer for both
	the IKE and Child SAs using "Proposals". Each proposal specifies an
	encryption and authentication algorithm, or an AEAD algorithm, a
	Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
	algorithm. Each peer may support multiple proposals, and the most
	preferred mutually supported proposal is chosen during the handshake.
	The authentication phase of IKEv2 may use Shared Secrets,
	Certificates, Digital Signatures, or an EAP (Extensible
	Authentication Protocol) method. At a minimum, IKEv2 takes two round
	trips to set up both an IKE SA and a Child SA. If EAP is used, this
	exchange may be expanded.
	Any SA used by IKEv2 can be re-keyed before expiration, which is
	usually based either on time or number of bytes encrypted.
	There is an extension to IKEv2 that allows session resumption
	[RFC5723].
	MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
	set of Security Associations to migrate over different outer IP
	addresses and interfaces [RFC4555].
	When UDP is not available or well-supported on a network, IKEv2 may
	be encapsulated in TCP [RFC8229].
	4.4.2. ESP Protocol Description
	ESP is a protocol that encrypts and authenticates IPv4 and IPv6
	packets. The keys used for both encryption and authentication can be
	derived from an IKEv2 exchange. ESP Security Associations come as
	pairs, one for each direction between two peers. Each SA is
	identified by a Security Parameter Index (SPI), which is marked on
	each encrypted ESP packet.
	ESP packets include the SPI, a sequence number, an optional
	Initialization Vector (IV), payload data, padding, a length and next
	header field, and an Integrity Check Value.
	From [RFC4303], "ESP is used to provide confidentiality, data origin
	authentication, connectionless integrity, an anti-replay service (a
	form of partial sequence integrity), and limited traffic flow
	confidentiality."
	Since ESP operates on IP packets, it is not directly tied to the
	transport protocols it encrypts. This means it requires little or no
	change from transports in order to provide security.
	ESP packets may be sent directly over IP, but where network
	conditions warrant (e.g., when a NAT is present or when a firewall
	blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP
	[RFC8229].
	4.4.3. IKEv2 Security Features
	o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.
	o Peer authentication (certificate, raw public key, pre-shared key,
	and EAP).
	o Unilateral responder authentication.
	o Mutual authentication.
	o Record (datagram) confidentiality and integrity.
	o Session resumption.
	o Connection mobility.
	o DoS mitigation (cookie-based).
	4.4.4. ESP Security Features
	o Record confidentiality and integrity.
	o Record replay protection.
	4.4.5. IKEv2 Protocol Dependencies
	o Availability of UDP to negotiate, or implementation support for
	TCP-encapsulation.
	o Some EAP authentication types require accessing a hardware device,
	such as a SIM card; or interacting with a user, such as password
	prompting.
	4.4.6. ESP Protocol Dependencies
	o Since ESP is below transport protocols, it does not have any
	dependencies on the transports themselves, other than on UDP or
	TCP where encapsulation is employed.
	4.5. Secure RTP (with DTLS)
	Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
	message authentication, and replay protection for RTP data packets
	and RTP control protocol (RTCP) packets [RFC3711].
	4.5.1. Protocol description
	SRTP adds confidentiality and optional integrity protection to RTP
	data packets, and adds confidentially and mandatory integrity
	protection to RTCP packets. For RTP data packets, this is done by
	encrypting the payload section of the packet and optionally appending
	an authentication tag (MAC) as a packet trailer, with the RTP header
	authenticated but not encrypted (the RTP header was left unencrypted
	to enable RTP header compression [RFC2508] [RFC3545]). For RTCP
	packets, the first packet in the compound RTCP packet is partially
	encrypted, leaving the first eight octets of the header as clear-text
	to allow identification of the packet as RTCP, while the remainder of
	the compound packet is fully encrypted. The entire RTCP packet is
	then authenticated by appending a MAC as packet trailer.
	Packets are encrypted using session keys, which are ultimately
	derived from a master key and an additional master salt and session
	salt. SRTP packets carry a 2-byte sequence number to partially
	identify the unique packet index. SRTP peers maintain a separate
	roll-over counter (ROC) for RTP data packets that is incremented
	whenever the sequence number wraps. The sequence number and ROC
	together determine the packet index. RTCP packets have a similar,
	yet differently named, field called the RTCP index which serves the
	same purpose.
	Numerous encryption modes are supported. For popular modes of
	operation, e.g., AES-CTR, the (unique) initialization vector (IV)
	used for each encryption mode is a function of the RTP SSRC
	(synchronization source), packet index, and session "salting key".
	SRTP offers replay detection by keeping a replay list of already seen
	and processed packet indices. If a packet arrives with an index that
	matches one in the replay list, it is silently discarded.
	DTLS [RFC5764] is commonly used to perform mutual authentication and
	key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual
	certificate-based authentication on the media path, and to generate
	the SRTP master key. Peer certificates can be issued and signed by a
	certificate authority. Alternatively, certificates used in the DTLS
	exchange can be self-signed. If they are self-signed, certificate
	fingerprints are included in the signaling exchange (e.g., in SIP or
	WebRTC), and used to bind the DTLS key exchange in the media plane to
	the signaling plane. The combination of a mutually authenticated
	DTLS key exchange on the media path and a fingerprint sent in the
	signaling channel protects against active attacks on the media,
	provided the signaling can be trusted. Signaling needs to be
	protected as described in, for example, SIP [RFC3261] Authenticated
	Identity Management [RFC8224] or the WebRTC security architecture
	[I-D.ietf-rtcweb-security-arch], to provide complete system security.
	4.5.2. Security Features
	o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.
	o Mutual authentication.
	o Partial datagram confidentiality. (Packet headers are not
	encrypted.)
	o Optional authentication of data packets.
	o Mandatory authentication of control packets.
	o Out-of-order record receipt.
	4.5.3. Protocol Dependencies
	o Secure RTP can run over UDP or TCP.
	o External key derivation and management protocol, e.g., DTLS
	[RFC5763].
	o External identity management protocol, e.g., SIP Authenticated
	Identity Management [RFC8224], WebRTC Security Architecture
	[I-D.ietf-rtcweb-security-arch].
	4.5.4. Variant: ZRTP for Media Path Key Agreement
	ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
	uses standard SRTP to protect RTP data packets and RTCP packets, but
	provides alternative key agreement and identity management protocols.
	Key agreement is performed using a Diffie-Hellman key exchange that
	runs on the media path. This generates a shared secret that is then
	used to generate the master key and salt for SRTP.
	ZRTP does not rely on a PKI or external identity management system.
	Rather, it uses an ephemeral Diffie-Hellman key exchange with hash
	commitment to allow detection of man-in-the-middle attacks. This
	requires endpoints to display a short authentication string that the
	users must read and verbally compare to validate the hashes and
	ensure security. Endpoints cache some key material after the first
	call to use in subsequent calls; this is mixed in with the Diffie-
	Hellman shared secret, so the short authentication string need only
	be checked once for a given user. This gives key continuity
	properties analogous to the secure shell (ssh) [RFC4253].
	4.6. tcpcrypt
	Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for		Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
	opportunistic encryption. Applications may use tcpcrypt's unique		opportunistic encryption. Applications may use tcpcrypt's unique
	session ID for further application-level authentication. Absent this		session ID for further application-level authentication. Absent this
	authentication, tcpcrypt is vulnerable to active attacks.		authentication, tcpcrypt is vulnerable to active attacks.
	4.6.1. Protocol Description		3.3.4. MinimalT
	Tcpcrypt extends TCP to enable opportunistic encryption between the
	two ends of a TCP connection [RFC8548]. It is a family of TCP
	encryption protocols (TEP), distinguished by key exchange algorithm.
	The use of a TEP is negotiated with a TCP option during the initial
	TCP handshake via the mechanism described by TCP Encryption
	Negotiation Option (ENO) [RFC8547]. In the case of initial session
	establishment, once a tcpcrypt TEP has been negotiated the key
	exchange occurs within the data segments of the first few packets
	exchanged after the handshake completes. The initiator of a
	connection sends a list of supported AEAD algorithms, a random nonce,
	and an ephemeral public key share. The responder typically chooses a
	mutually-supported AEAD algorithm and replies with this choice, its
	own nonce, and ephemeral key share. An initial shared secret is
	derived from the ENO handshake, the tcpcrypt handshake, and the
	initial keying material resulting from the key exchange. The traffic
	encryption keys on the initial connection are derived from the shared
	secret. Connections can be re-keyed before the natural AEAD limit
	for a single set of traffic encryption keys is reached.
	Each tcpcrypt session is associated with a ladder of resumption IDs,
	each derived from the respective entry in a ladder of shared secrets.
	These resumption IDs can be used to negotiate a stateful resumption
	of the session in a subsequent connection, resulting in use of a new
	shared secret and traffic encryption keys without requiring a new key
	exchange. Willingness to resume a session is signaled via the ENO
	option during the TCP handshake. Given the length constraints
	imposed by TCP options, unlike stateless resumption mechanisms (such
	as that provided by session tickets in TLS) resumption in tcpcrypt
	requires the maintenance of state on the server, and so successful
	resumption across a pool of servers implies shared state.
	Owing to middlebox ossification issues, tcpcrypt only protects the
	payload portion of a TCP packet. It does not encrypt any header
	information, such as the TCP sequence number.
	4.6.2. Security Features
	o Forward-secure session key establishment.
	o Record (channel) confidentiality and integrity.		MinimalT is a UDP-based transport security protocol designed to offer
			confidentiality, mutual authentication, DoS prevention, and
			connection mobility [MinimalT]. One major goal of the protocol is to
			leverage existing protocols to obtain server-side configuration
			information used to more quickly bootstrap a connection. MinimalT
			uses a variant of TCP's congestion control algorithm.
	o Stateful cross-connection session resumption.		3.3.5. CurveCP
	o Session caching and management.		CurveCP [CurveCP] is a UDP-based transport security protocol from
			Daniel J. Bernstein. Unlike other security protocols, it is based
			entirely upon highly efficient public key algorithms. This removes
			many pitfalls associated with nonce reuse and key synchronization.
			CurveCP provides its own reliability for application data as part of
			its protocol.
	o Application authentication delegation.		3.4. Packet Security Protocols
	4.6.3. Protocol Dependencies		The following protocols provide protection for IP packets. These are
			generally used as tunnels, such as for Virtual Private Networks
			(VPNs). Often, applications will not interact directly with these
			protocols. However, applications that implement tunnels will
			interact directly with these protocols.
	o TCP for in-order, reliable transport.		3.4.1. IKEv2 with ESP
	o TCP Encryption Negotiation Option (ENO).		IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
			protocol suite that encrypts and authenticates IP packets, either for
			creating tunnels (tunnel-mode) or for direct transport connections
			(transport-mode). This suite of protocols separates out the key
			generation protocol (IKEv2) from the transport encryption protocol
			(ESP). Each protocol can be used independently, but this document
			considers them together, since that is the most common pattern.
	4.7. WireGuard		3.4.2. WireGuard
	WireGuard is a layer 3 protocol designed as an alternative to IPsec		WireGuard is an IP-layer protocol designed as an alternative to IPsec
	[WireGuard] for certain use cases. It uses UDP to encapsulate IP		[WireGuard] for certain use cases. It uses UDP to encapsulate IP
	datagrams between peers. Unlike most transport security protocols,		datagrams between peers. Unlike most transport security protocols,
	which rely on PKI for peer authentication, WireGuard authenticates		which rely on PKI for peer authentication, WireGuard authenticates
	peers using pre-shared public keys delivered out-of-band, each of		peers using pre-shared public keys delivered out-of-band, each of
	which is bound to one or more IP addresses. Moreover, as a protocol		which is bound to one or more IP addresses. Moreover, as a protocol
	suited for VPNs, WireGuard offers no extensibility, negotiation, or		suited for VPNs, WireGuard offers no extensibility, negotiation, or
	cryptographic agility.		cryptographic agility.
	4.7.1. Protocol description		3.4.3. OpenVPN
	WireGuard is a simple VPN protocol that binds a pre-shared public key
	to one or more IP addresses. Users configure WireGuard by
	associating peer public keys with IP addresses. These mappings are
	stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]
	for more details and sample configurations.) These keys are used
	upon WireGuard packet transmission and reception. For example, upon
	receipt of a Handshake Initiation message, receivers use the static
	public key in their CryptoKey routing table to perform necessary
	cryptographic computations.
	WireGuard builds on Noise [Noise] for 1-RTT key exchange with
	identity hiding. The handshake hides peer identities as per the
	SIGMA construction [SIGMA]. As a consequence of using Noise,
	WireGuard comes with a fixed set of cryptographic algorithms:
	o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key
	derivation.
	o ChaCha20+Poly1305 [RFC8439] for packet authenticated encryption.
	o BLAKE2s [BLAKE2] for hashing.
	There is no cryptographic agility. If weaknesses are found in any of
	these algorithms, new message types using new algorithms must be
	introduced.
	If a WireGuard receiver is under heavy load and cannot process a
	packet, e.g., cannot spare CPU cycles for expensive public key
	cryptographic operations, it can reply with a cookie similar to DTLS
	and IKEv2. This cookie only proves IP address ownership. Any rate
	limiting scheme can be applied to packets coming from non-spoofed
	addresses.
	4.7.2. Security Features
	o Forward-secure session key establishment.
	o Peer authentication (public-key and PSK).
	o Mutual authentication.
	o Record replay prevention (Stateful, timestamp-based).
	o Connection mobility.
	o DoS mitigation (cookie-based).
	4.7.3. Protocol Dependencies
	o Datagram transport.
	o Out-of-band key distribution and management.
	4.8. CurveCP
	CurveCP [CurveCP] is a UDP-based transport security protocol from
	Daniel J. Bernstein. Unlike other transport security protocols, it
	is based entirely upon highly efficient public key algorithms. This
	removes many pitfalls associated with nonce reuse and key
	synchronization.
	4.8.1. Protocol Description
	CurveCP is a UDP-based transport security protocol. It is built on
	three principal features: exclusive use of public key authenticated
	encryption of packets, server-chosen cookies to prohibit memory and
	computation DoS at the server, and connection mobility with a client-
	chosen ephemeral identifier.
	There are two rounds in CurveCP. In the first round, the client
	sends its first initialization packet to the server, carrying its
	(possibly fresh) ephemeral public key C', with zero-padding encrypted
	under the server's long-term public key. The server replies with a
	cookie and its own ephemeral key S' and a cookie that is to be used
	by the client. Upon receipt, the client then generates its second
	initialization packet carrying: the ephemeral key C', cookie, and an
	encryption of C', the server's domain name, and, optionally, some
	message data. The server verifies the cookie and the encrypted
	payload and, if valid, proceeds to send data in return. At this
	point, the connection is established and the two parties can
	communicate.
	The use of public-key encryption and authentication, or "boxing",
	simplifies problems that come with symmetric key management and nonce
	synchronization. For example, it allows the sender of a message to
	be in complete control of each message's nonce. It does not require
	either end to share secret keying material. Furthermore, it allows
	connections (or sessions) to be associated with unique ephemeral
	public keys as a mechanism for enabling forward secrecy given the
	risk of long-term private key compromise.
	The client and server do not perform a standard key exchange.
	Instead, in the initial exchange of packets, each party provides its
	own ephemeral key to the other end. The client can choose a new
	ephemeral key for every new connection. However, the server must
	rotate these keys on a slower basis. Otherwise, it would be trivial
	for an attacker to force the server to create and store ephemeral
	keys with a fake client initialization packet.
	Servers use cookies for source validation. After receiving a
	client's initial packet, encrypted under the server's long-term
	public key, a server generates and returns a stateless cookie that
	must be echoed back in the client's following message. This cookie
	is encrypted under the client's ephemeral public key. This stateless
	technique prevents attackers from hijacking client initialization
	packets to obtain cookie values to flood clients. (A client would
	detect the duplicate cookies and reject the flooded packets.)
	Similarly, replaying the client's second packet, carrying the cookie,
	will be detected by the server.
	CurveCP supports client authentication by allowing clients to send
	their long-term public keys in the second initialization packet. A
	server can verify this public key and, if untrusted, drop the
	connection and subsequent data.
	Unlike some other protocols, CurveCP data packets leave only the
	ephemeral public key, connection ID, and per-message nonce in the
	clear. All other data is encrypted.
	4.8.2. Protocol Features
	o Datagram confidentiality and integrity (via public key
	encryption).
	o Peer authentication (public-key).
	o Unilateral responder authentication.
	o Mutual authentication.
	o Connection mobility (based on a client-chosen ephemeral
	identifier).
	o Optional length-hiding and anti-amplification padding.
	o Source validation (cookie-based)
	4.8.3. Protocol Dependencies
	o An unreliable transport protocol such as UDP.
	4.9. MinimalT		OpenVPN [OpenVPN] is a commonly used protocol designed as an
			alternative to IPsec. A major goal of this protocol is to provide a
			VPN that is simple to configure and works over a variety of
			transports. OpenVPN encapsulates either IP packets or Ethernet
			frames within a secure tunnel and can run over UDP or TCP.
	MinimalT is a UDP-based transport security protocol designed to offer		4. Transport Dependencies
	confidentiality, mutual authentication, DoS prevention, and
	connection mobility [MinimalT]. One major goal of the protocol is to
	leverage existing protocols to obtain server-side configuration
	information used to more quickly bootstrap a connection. MinimalT
	uses a variant of TCP's congestion control algorithm.
	4.9.1. Protocol Description		Across the different security protocols listed above, the primary
			dependency on transport protocols is the presentation of data: either
			an unbounded stream of bytes, or framed messages. Within protocols
			that rely on the transport for message framing, most are built to run
			over transports that inherently provide framing, like UDP, but some
			also define how their messages can be framed over byte-stream
			transports.
	MinimalT is a secure transport protocol built on top of a widespread		4.1. Reliable Byte-Stream Transports
	directory service. Clients and servers interact with local directory
	services to (a) resolve server information and (b) publish ephemeral
	state information, respectively. Clients connect to a local resolver
	once at boot time. Through this resolver they recover the IP
	address(es) and public key(s) of each server to which they want to
	connect.
	Connections are instances of user-authenticated, mobile sessions		The following protocols all depend upon running on a transport
	between two endpoints. Connections run within tunnels between hosts.		protocol that provides a reliable, in-order stream of bytes. This is
	A tunnel is a server-authenticated container that multiplexes		typically TCP.
	multiple connections between the same hosts. All connections in a
	tunnel share the same transport state machine and encryption. Each
	tunnel has a dedicated control connection used to configure and
	manage the tunnel over time. Moreover, since tunnels are independent
	of the network address information, they may be reused as both ends
	of the tunnel move about the network. This does however imply that
	connection establishment and packet encryption mechanisms are
	coupled.
	Before a client connects to a remote service, it must first establish		Application Payload Security Protocols:
	a tunnel to the host providing or offering the service. Tunnels are
	established in 1-RTT using an ephemeral key obtained from the
	directory service. Tunnel initiators provide their own ephemeral key
	and, optionally, a DoS puzzle solution such that the recipient
	(server) can verify the authenticity of the request and derive a
	shared secret. Within a tunnel, new connections to services may be
	established.
	Additional (orthogonal) transport features include: connection		o TLS
	multiplexing between hosts across shared tunnels, and congestion
	control state is shared across connections between the same host
	pairs.
	4.9.2. Protocol Features		Transport-Layer Security Protocols:
	o Record or datagram confidentiality and integrity.		o tcpcrypt
	o Forward-secure session key establishment.		Packet Security Protocols:
	o Peer authentication (public-key).		o OpenVPN
	o Unilateral responder authentication.		4.2. Unreliable Datagram Transports
	o DoS mitigation (puzzle-based).		The following protocols all depend on the transport protocol to
			provide message framing to encapsulate their data. These protocols
			are built to run using UDP, and thus do not have any requirement for
			reliability. Running these protocols over a protocol that does
			provide reliability will not break functionality, but may lead to
			multiple layers of reliability if the security protocol is
			encapsulating other transport protocol traffic.
	o Out-of-order receipt record.		Application Payload Security Protocols:
	o Connection mobility (based on tunnel identifiers).		o DTLS
	4.9.3. Protocol Dependencies		o SRTP
	o An unreliable transport protocol such as UDP.		o ZRTP
	o A DNS-like resolution service to obtain location information (an		Transport-Layer Security Protocols:
	IP address) and ephemeral keys.
	o A PKI trust store for certificate validation.		o QUIC
	4.10. OpenVPN		o MinimalT
	OpenVPN [OpenVPN] is a commonly used protocol designed as an		o CurveCP
	alternative to IPsec. A major goal of this protocol is to provide a
	VPN that is simple to configure and works over a variety of
	transports. OpenVPN encapsulates either IP packets or Ethernet
	frames within a secure tunnel and can run over UDP or TCP.
	4.10.1. Protocol Description		Packet Security Protocols:
	OpenVPN facilitates authentication using either a pre-shared static		o IKEv2 and ESP
	key or using X.509 certificates and TLS. In pre-shared key mode,
	OpenVPN derives keys for encryption and authentication directly from
	one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a
	TLS handshake, in which both peers must present a certificate for
	authentication. After the handshake, both sides contribute random
	source material to derive keys for encryption and authentication
	using the TLS pseudo random function (PRF). OpenVPN provides the
	possibility to authenticate and encrypt the TLS handshake itself
	using a pre-shared key or passphrase. Furthermore, it supports re-
	keying using TLS.
	After authentication and key exchange, OpenVPN encrypts payload data,		o WireGuard
	i.e., IP packets or Ethernet frames, and authenticates the payload
	using HMAC. Applications can select an arbitrary encryption
	algorithm (cipher) and key size, as well hash function for HMAC. The
	default cipher and hash functions are AES-GCM and SHA1, respectively.
	Recent versions of the protocol support cipher negotiation.
	OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN		4.2.1. Datagram Protocols with Defined Byte-Stream Mappings
	provides a simple reliability layer for control packets such as the
	TLS handshake and key exchange. It assigns sequence numbers to
	packets, acknowledges packets it receives, and retransmits packets it
	deems lost. Similar to DTLS, this reliability layer is not used for
	data packets, which prevents the problem of two reliability
	mechanisms being encapsulated within each other. When running over
	TCP, OpenVPN includes the packet length in the header, which allows
	the peer to deframe the TCP stream into messages.
	For replay protection, OpenVPN assigns an identifier to each outgoing		Of the protocols listed above that depend on the transport for
	packet, which is unique for the packet and the currently used key.		message framing, some do have well-defined mappings for sending their
	In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN		messages over byte-stream transports like TCP.
	combines a timestamp with an incrementing sequence number into a
	64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits
	the timestamp, so identifiers are only 32-bit. This is sufficient
	since OpenVPN can guarantee the uniqueness of this identifier for
	each key, as it can trigger re-keying if needed.
	OpenVPN supports connection mobility by allowing a peer to change its		Application Payload Security Protocols:
	IP address during an ongoing session. When configured accordingly, a
	host will accept authenticated packets for a session from any IP
	address.
	4.10.2. Protocol Features		o SRTP [RFC7201]
	o Peer authentication using certificates or pre-shared key.		Packet Security Protocols:
	o Mandatory mutual authentication.		o IKEv2 and ESP [RFC8229]
	o Connection mobility.		4.3. Transport-Specific Dependencies
	o Out-of-order record receipt.		One protocol surveyed, tcpcrypt, has an direct dependency on a
			feature in the transport that is needed for its functionality.
			Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP
			Encryption Negotiation Option (ENO) [RFC8547] to negotiate its
			protocol support.
	o Length-hiding padding.		QUIC, CurveCP, and MinimalT provide both transport functionality and
			security functionality. They have a dependencies on running over a
			framed protocol like UDP, but they add their own layers of
			reliability and other transport services. Thus, an application that
			uses one of these protocols cannot decouple the security from
			transport functionality.
	See also the properties of TLS.		5. Application Interface
	4.10.3. Protocol Dependencies		This section describes the interface surface exposed by the security
			protocols described above. Note that not all protocols support each
			interface. We partition these interfaces into pre-connection
			(configuration), connection, and post-connection interfaces,
			following conventions in [I-D.ietf-taps-interface] and
			[I-D.ietf-taps-arch].
	o For control packets such as handshake and key exchange: Reliable,		5.1. Pre-Connection Interfaces
	in-order transport. Reliability is provided either by TCP, or by
	OpenVPN's own reliability layer when using UDP.
	5. Security Features and Application Dependencies		Configuration interfaces are used to configure the security protocols
			before a handshake begins or the keys are negotiated.
	There exists a common set of features shared across the transport		o Identities and Private Keys: The application can provide its
	protocols surveyed in this document. Mandatory features constitute a		identities (certificates) and private keys, or mechanisms to
	baseline of functionality that an application may assume for any		access these, to the security protocol to use during handshakes.
	Transport Services implementation. They were selected on the basis
	that they are either (a) required for any secure transport protocol
	or (b) nearly ubiquitous amongst common secure transport protocols.
	Optional features by contrast may vary from implementation to		* TLS
	implementation, and so an application cannot simply assume they are
	available. Applications learn of and use optional features by
	querying for their presence and support. Optional features may not
	be implemented, or may be disabled if their presence impacts
	transport services or if a necessary transport service or application
	dependency is unavailable.
	In this context, an application dependency is an aspect of the		* DTLS
	security feature which can be exposed to the application. An
	application dependency may be required for the security feature to
	function, or it may provide additional information and control to the
	application. For example, an application may need to provide
	information such as keying material or authentication credentials, or
	it may want to restrict which cryptographic algorithms to allow for
	negotiation.
	5.1. Mandatory Features		* SRTP
	Mandatory features must be supported regardless of transport and		* QUIC
	application services available. Note that not all mandatory features
	are provided by each surveyed protocol above. For example, tcpcrypt
	does not provide responder authentication and CurveCP does not
	provide forward-secure session key establishment.
	o Record or datagram confidentiality and integrity.		* MinimalT
	* Application dependency: None.		* CurveCP
	o Forward-secure session key establishment.		* IKEv2
	* Application dependency: None.		* WireGuard
	o Unilateral responder authentication.		o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites):
			The application can choose the algorithms that are supported for
			key exchange, signatures, and ciphersuites.
	* (Optional) Application dependency: Application-provided trust		* TLS
	information. System trust stores may also be used to
	authenticate responders.
	5.2. Optional Features		* DTLS
	In this section we list optional features along with their necessary		* SRTP
	application dependencies, if any.
	o Pre-shared key support (PSK):		* QUIC
	* Application dependency: Application provisioning and		* tcpcrypt
	distribution of pre-shared keys.
	o Mutual authentication (MA):		* MinimalT
	* Application dependency: Mutual authentication credentials		* IKEv2
	required.
	o Cryptographic algorithm negotiation (AN):		o Extensions (Application-Layer Protocol Negotiation): The
			application enables or configures extensions that are to be
			negotiated by the security protocol, such as ALPN [RFC7301].
	* Application dependency: Application awareness of supported or		* TLS
	desired algorithms.
	o Application authentication delegation (AD):		* DTLS
	* Application dependency: Application opt-in and policy for		* QUIC
	endpoint authentication.
	o DoS mitigation (DM):		o Session Cache Management: The application provides the ability to
			save and retrieve session state (such as tickets, keying material,
			and server parameters) that may be used to resume the security
			session.
	* Application dependency: None.		* TLS
	o Connection mobility (CM):		* DTLS
	* Application dependency: None.		* QUIC
	o Source validation (SV):		* MinimalT
	* Application dependency: None.		o Authentication Delegation: The application provides access to a
			separate module that will provide authentication, using EAP for
			example.
	o Application-layer feature negotiation (AFN):		* SRTP
	* Application dependency: Specification of application-layer		* IKEv2
	features or functionality.
	o Configuration extensions (CX):		o Pre-Shared Key Import: Either the handshake protocol or the
			application directly can supply pre-shared keys for the record
			protocol use for encryption/decryption and authentication. If the
			application can supply keys directly, this is considered explicit
			import; if the handshake protocol traditionally provides the keys
			directly, it is considered direct import; if the keys can only be
			shared by the handshake, they are considered non-importable.
	* Application dependency: Specification of application-specific		* Explicit import: QUIC, ESP
	extensions.
	o Session caching and management (SC):		* Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard
	* Application dependency: None.		* Non-importable: CurveCP
	o Length-hiding padding (LHP): (Optional) Application dependency:		5.2. Connection Interfaces
	Knowledge of desired padding policies. Some protocols, such as
	IKE, can negotiate application-agnostic padding policies.
	o Early data support (ED):		o Identity Validation: During a handshake, the security protocol
			will conduct identity validation of the peer. This can call into
			the application to offload validation.
	* Application dependency: Anti-replay protections or hints of		* TLS
	data idempotency.
	o Record replay prevention (RP):		* DTLS
	* Application dependency: None.		* SRTP
	o Out-of-order receipt record (OO):		* QUIC
	* Application dependency: None.		* MinimalT
	5.3. Optional Feature Availability		* CurveCP
	The following table lists the availability of the above-listed		* IKEv2
	optional features in each of the analyzed protocols. "Mandatory"
	indicates that the feature is intrinsic to the protocol and cannot be
	disabled. "Supported" indicates that the feature is optionally
	provided natively or through a (standardized, where applicable)
	extension.
	+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+		* WireGuard
	| Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO |
	| toc | S | N | D | A | M | M | V | F | | | P | | | |
	| ol | K | | | | | | | N | | | | | | |
	+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
	| TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U |
	| | | | | | | * | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M |
	| S | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| QUI | S | S | S | S | S | S | M | S | S | S | S | S | M | M |
	| C | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M |
	| v2+ | | | | | | | | | | | | | | |
	| ESP | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M |
	| P+D | | | | | | | | | | | | | | |
	| TLS | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U |
	| cry | | | | | * | * | | | | | | | | |
	| pt | | | | | * | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M |
	| eGu | | | | | | | | | | | | | | |
	| ard | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U |
	| ima | | | | | | | | | | | | | | |
	| lT | | | | | | | | | | | | | | |
	| | | | | | | | | | | | | | | |
	| Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M |
	| veC | | | | | | | | | | | | | | |
	| P | | | | | | | | | | | | | | |
	+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
	M=Mandatory S=Supported but not required U=Unsupported *=On TCP;		* OpenVPN
	MPTCP would provide this ability **=TCP provides SYN cookies
	natively, but these are not cryptographically strong +=For transport
	packets only
	6. Transport Security Protocol Interfaces		o Source Address Validation: The handshake protocol may delegate
			validation of the remote peer that has sent data to the transport
			protocol or application. This involves sending a cookie exchange
			to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
	This section describes the interface surface exposed by the security		* DTLS
	protocols described above. Note that not all protocols support each
	interface. We partition these interfaces into pre-connection
	(configuration), connection, and post-connection interfaces,
	following conventions in [I-D.ietf-taps-interface] and
	[I-D.ietf-taps-arch].
	6.1. Pre-Connection Interfaces		* QUIC
	Configuration interfaces are used to configure the security protocols		* WireGuard
	before a handshake begins or the keys are negotiated.
	o Identities and Private Keys The application can provide its		5.3. Post-Connection Interfaces
	identities (certificates) and private keys, or mechanisms to
	access these, to the security protocol to use during handshakes.
	Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2,
	WireGuard, SRTP
	o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)		o Connection Termination: The security protocol may be instructed to
	The application can choose the algorithms that are supported for		tear down its connection and session information. This is needed
	key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS,		by some protocols to prevent application data truncation attacks.
	QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP
	o Extensions (Application-Layer Protocol Negotiation): The		* TLS
	application enables or configures extensions that are to be
	negotiated by the security protocol, such as ALPN [RFC7301].
	Protocols: TLS, DTLS, QUIC + TLS
	o Session Cache Management The application provides the ability to		* DTLS
	save and retrieve session state (such as tickets, keying material,
	and server parameters) that may be used to resume the security
	session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT
	o Authentication Delegation The application provides access to a		* QUIC
	separate module that will provide authentication, using EAP for
	example. Protocols: IKEv2, SRTP
	o Pre-Shared Key Import Either the handshake protocol or the		* tcpcrypt
	application directly can supply pre-shared keys for the record		* MinimalT
	protocol use for encryption/decryption and authentication. If the
	application can supply keys directly, this is considered explicit
	import; if the handshake protocol traditionally provides the keys
	directly, it is considered direct import; if the keys can only be
	shared by the handshake, they are considered non-importable.
	* Explicit import: QUIC, ESP		* IKEv2
	* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard
	* Non-importable: CurveCP		o Key Update: The handshake protocol may be instructed to update its
			keying material, either by the application directly or by the
			record protocol sending a key expiration event.
	6.2. Connection Interfaces		* TLS
	o Identity Validation During a handshake, the security protocol will		* DTLS
	conduct identity validation of the peer. This can call into the
	application to offload validation. Protocols: All (TLS, DTLS,
	QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
	o Source Address Validation The handshake protocol may delegate		* QUIC
	validation of the remote peer that has sent data to the transport
	protocol or application. This involves sending a cookie exchange
	to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
	6.3. Post-Connection Interfaces		* tcpcrypt
	o Connection Termination The security protocol may be instructed to		* MinimalT
	tear down its connection and session information. This is needed
	by some protocols to prevent application data truncation attacks.
	Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT
	o Key Update The handshake protocol may be instructed to update its		* IKEv2
	keying material, either by the application directly or by the
	record protocol sending a key expiration event. Protocols: TLS,
	DTLS, QUIC, tcpcrypt, IKEv2, MinimalT
	o Pre-Shared Key Export The handshake protocol will generate one or		o Pre-Shared Key Export: The handshake protocol will generate one or
	more keys to be used for record encryption/decryption and		more keys to be used for record encryption/decryption and
	authentication. These may be explicitly exportable to the		authentication. These may be explicitly exportable to the
	application, traditionally limited to direct export to the record		application, traditionally limited to direct export to the record
	protocol, or inherently non-exportable because the keys must be		protocol, or inherently non-exportable because the keys must be
	used directly in conjunction with the record protocol.		used directly in conjunction with the record protocol.
	* Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for		* Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt,
	SRTP)		IKEv2
	* Direct export: TLS, DTLS, MinimalT		* Direct export: TLS, DTLS, MinimalT
	* Non-exportable: CurveCP		* Non-exportable: CurveCP
	o Key Expiration The record protocol can signal that its keys are		o Key Expiration: The record protocol can signal that its keys are
	expiring due to reaching a time-based deadline, or a use-based		expiring due to reaching a time-based deadline, or a use-based
	deadline (number of bytes that have been encrypted with the key).		deadline (number of bytes that have been encrypted with the key).
	This interaction is often limited to signaling between the record		This interaction is often limited to signaling between the record
	layer and the handshake layer. Protocols: ESP ((Editor's note:		layer and the handshake layer.
	One may consider TLS/DTLS to also have this interface))
	o Mobility Events The record protocol can be signaled that it is		* ESP
			o Mobility Events: The record protocol can be signaled that it is
	being migrated to another transport or interface due to connection		being migrated to another transport or interface due to connection
	mobility, which may reset address and state validation and induce		mobility, which may reset address and state validation and induce
	state changes such as use of a new Connection Identifier (CID).		state changes such as use of a new Connection Identifier (CID).
	Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming)
	7. IANA Considerations		* QUIC
			* MinimalT
			* CurveCP
			* ESP
			* WireGuard
			6. IANA Considerations
	This document has no request to IANA.		This document has no request to IANA.
	8. Security Considerations		7. Security Considerations
	This document summarizes existing transport security protocols and		This document summarizes existing transport security protocols and
	their interfaces. It does not propose changes to or recommend usage		their interfaces. It does not propose changes to or recommend usage
	of reference protocols. Moreover, no claims of security and privacy		of reference protocols. Moreover, no claims of security and privacy
	properties beyond those guaranteed by the protocols discussed are		properties beyond those guaranteed by the protocols discussed are
	made. For example, metadata leakage via timing side channels and		made. For example, metadata leakage via timing side channels and
	traffic analysis may compromise any protocol discussed in this		traffic analysis may compromise any protocol discussed in this
	survey. Applications using Security Interfaces should take such		survey. Applications using Security Interfaces should take such
	limitations into consideration when using a particular protocol		limitations into consideration when using a particular protocol
	implementation.		implementation.
	9. Privacy Considerations		8. Privacy Considerations
	Analysis of how features improve or degrade privacy is intentionally		Analysis of how features improve or degrade privacy is intentionally
	omitted from this survey. All security protocols surveyed generally		omitted from this survey. All security protocols surveyed generally
	improve privacy by reducing information leakage via encryption.		improve privacy by reducing information leakage via encryption.
	However, varying amounts of metadata remain in the clear across each		However, varying amounts of metadata remain in the clear across each
	protocol. For example, client and server certificates are sent in		protocol. For example, client and server certificates are sent in
	cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3		cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
	[RFC8446]. A survey of privacy features, or lack thereof, for		[RFC8446]. A survey of privacy features, or lack thereof, for
	various security protocols could be addressed in a separate document.		various security protocols could be addressed in a separate document.
	10. Acknowledgments		9. Acknowledgments
	The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja		The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
	Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for		Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
	their input and feedback on this draft.		their input and feedback on this draft.
	11. Informative References		10. Informative References
	[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,		[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,
	B., and J. Boeuf, "Application Layer Transport Security",		B., and J. Boeuf, "Application Layer Transport Security",
	<https://cloud.google.com/security/encryption-in-transit/		<https://cloud.google.com/security/encryption-in-transit/
	application-layer-transport-security/>.		application-layer-transport-security/>.
	[BLAKE2] Aumasson, J., Neves, S., Wilcox-O'Hearn, Z., and C.
	Winnerlein, "BLAKE2 -- simpler, smaller, fast as MD5",
	<https://blake2.net/blake2.pdf>.
	[Curve25519]
	Bernstein, D., "Curve25519 - new Diffie-Hellman speed
	records", <https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
	[CurveCP] Bernstein, D., "CurveCP -- Usable security for the		[CurveCP] Bernstein, D., "CurveCP -- Usable security for the
	Internet", <http://curvecp.org>.		Internet", <http://curvecp.org>.
	[I-D.ietf-quic-tls]		[I-D.ietf-quic-tls]
	Thomson, M. and S. Turner, "Using TLS to Secure QUIC",		Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
	draft-ietf-quic-tls-23 (work in progress), September 2019.		draft-ietf-quic-tls-23 (work in progress), September 2019.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-23 (work		and Secure Transport", draft-ietf-quic-transport-23 (work
	in progress), September 2019.		in progress), September 2019.
	[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-20 (work in progress), July 2019.
	[I-D.ietf-taps-arch]		[I-D.ietf-taps-arch]
	Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,		Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
	Perkins, C., Tiesel, P., and C. Wood, "An Architecture for		Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
	Transport Services", draft-ietf-taps-arch-04 (work in		Transport Services", draft-ietf-taps-arch-04 (work in
	progress), July 2019.		progress), July 2019.
	[I-D.ietf-taps-interface]		[I-D.ietf-taps-interface]
	Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,		Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
	Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.		Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
	Pauly, "An Abstract Application Layer Interface to		Pauly, "An Abstract Application Layer Interface to
	Transport Services", draft-ietf-taps-interface-04 (work in		Transport Services", draft-ietf-taps-interface-04 (work in
	progress), July 2019.		progress), July 2019.
	[I-D.ietf-taps-minset]
	Welzl, M. and S. Gjessing, "A Minimal Set of Transport
	Services for End Systems", draft-ietf-taps-minset-11 (work
	in progress), September 2018.
	[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
	Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
	id-06 (work in progress), July 2019.
	[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-32 (work in progress), July
	2019.
	[MinimalT]		[MinimalT]
	Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and		Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and
	T. Lange, "MinimaLT -- Minimal-latency Networking Through		T. Lange, "MinimaLT -- Minimal-latency Networking Through
	Better Security",		Better Security",
	<http://dl.acm.org/citation.cfm?id=2516737>.		<http://dl.acm.org/citation.cfm?id=2516737>.
	[Noise] Perrin, T., "The Noise Protocol Framework",
	<http://noiseprotocol.org/noise.pdf>.
	[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/		[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/
	community-resources/openvpn-cryptographic-layer/>.		community-resources/openvpn-cryptographic-layer/>.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, DOI 10.17487/RFC2385, August		Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
	1998, <https://www.rfc-editor.org/info/rfc2385>.		1998, <https://www.rfc-editor.org/info/rfc2385>.
	[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
	Headers for Low-Speed Serial Links", RFC 2508,
	DOI 10.17487/RFC2508, February 1999,
	<https://www.rfc-editor.org/info/rfc2508>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.
	[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
	P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
	High Delay, Packet Loss and Reordering", RFC 3545,
	DOI 10.17487/RFC3545, July 2003,
	<https://www.rfc-editor.org/info/rfc3545>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<https://www.rfc-editor.org/info/rfc3711>.		<https://www.rfc-editor.org/info/rfc3711>.
	[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
	Stenberg, "UDP Encapsulation of IPsec ESP Packets",
	RFC 3948, DOI 10.17487/RFC3948, January 2005,
	<https://www.rfc-editor.org/info/rfc3948>.
	[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
	January 2006, <https://www.rfc-editor.org/info/rfc4253>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,		DOI 10.17487/RFC4302, December 2005,
	<https://www.rfc-editor.org/info/rfc4302>.		<https://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
	(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
	<https://www.rfc-editor.org/info/rfc4555>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
	Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
	DOI 10.17487/RFC5723, January 2010,
	<https://www.rfc-editor.org/info/rfc5723>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764,
	DOI 10.17487/RFC5764, May 2010,
	<https://www.rfc-editor.org/info/rfc5764>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <https://www.rfc-editor.org/info/rfc5925>.		June 2010, <https://www.rfc-editor.org/info/rfc5925>.
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,
	DOI 10.17487/RFC6066, January 2011,
	<https://www.rfc-editor.org/info/rfc6066>.
	[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:		[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
	Media Path Key Agreement for Unicast Secure RTP",		Media Path Key Agreement for Unicast Secure RTP",
	RFC 6189, DOI 10.17487/RFC6189, April 2011,		RFC 6189, DOI 10.17487/RFC6189, April 2011,
	<https://www.rfc-editor.org/info/rfc6189>.		<https://www.rfc-editor.org/info/rfc6189>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
	Weiler, S., and T. Kivinen, "Using Raw Public Keys in		Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
	Transport Layer Security (TLS) and Datagram Transport		<https://www.rfc-editor.org/info/rfc7201>.
	Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
	June 2014, <https://www.rfc-editor.org/info/rfc7250>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,		[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
	Ed., "Services Provided by IETF Transport Protocols and		Ed., "Services Provided by IETF Transport Protocols and
	Congestion Control Mechanisms", RFC 8095,		Congestion Control Mechanisms", RFC 8095,
	DOI 10.17487/RFC8095, March 2017,		DOI 10.17487/RFC8095, March 2017,
	<https://www.rfc-editor.org/info/rfc8095>.		<https://www.rfc-editor.org/info/rfc8095>.
	[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC8224, February 2018,
	<https://www.rfc-editor.org/info/rfc8224>.
	[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation		[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,		of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
	August 2017, <https://www.rfc-editor.org/info/rfc8229>.		August 2017, <https://www.rfc-editor.org/info/rfc8229>.
	[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
	<https://www.rfc-editor.org/info/rfc8439>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
	RFC 8449, DOI 10.17487/RFC8449, August 2018,
	<https://www.rfc-editor.org/info/rfc8449>.
	[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.		[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
	Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,		Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
	DOI 10.17487/RFC8547, May 2019,		DOI 10.17487/RFC8547, May 2019,
	<https://www.rfc-editor.org/info/rfc8547>.		<https://www.rfc-editor.org/info/rfc8547>.
	[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
	Q., and E. Smith, "Cryptographic Protection of TCP Streams		Q., and E. Smith, "Cryptographic Protection of TCP Streams
	(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,		(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
	<https://www.rfc-editor.org/info/rfc8548>.		<https://www.rfc-editor.org/info/rfc8548>.
	[SIGMA] Krawczyk, H., "SIGMA -- The 'SIGn-and-MAc' Approach to
	Authenticated Diffie-Hellman and Its Use in the IKE-
	Protocols", <http://www.iacr.org/cryptodb/archive/2003/
	CRYPTO/1495/1495.pdf>.
	[WireGuard]		[WireGuard]
	Donenfeld, J., "WireGuard -- Next Generation Kernel		Donenfeld, J., "WireGuard -- Next Generation Kernel
	Network Tunnel",		Network Tunnel",
	<https://www.wireguard.com/papers/wireguard.pdf>.		<https://www.wireguard.com/papers/wireguard.pdf>.
	Authors' Addresses		Authors' Addresses
	Christopher A. Wood (editor)
	Apple Inc.
	One Apple Park Way
	Cupertino, California 95014
	United States of America
	Email: cawood@apple.com
	Theresa Enghardt		Theresa Enghardt
	TU Berlin		TU Berlin
	Marchstr. 23		Marchstr. 23
	10587 Berlin		10587 Berlin
	Germany		Germany
	Email: theresa@inet.tu-berlin.de		Email: theresa@inet.tu-berlin.de
	Tommy Pauly		Tommy Pauly
	Apple Inc.		Apple Inc.
	skipping to change at page 37, line 27 ¶		skipping to change at page 19, line 4 ¶
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Colin Perkins		Colin Perkins
	University of Glasgow		University of Glasgow
	School of Computing Science		School of Computing Science
	Glasgow G12 8QQ		Glasgow G12 8QQ
	United Kingdom		United Kingdom
	Email: csp@csperkins.org		Email: csp@csperkins.org
	Kyle Rose		Kyle Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	150 Broadway		150 Broadway
	Cambridge, MA 02144		Cambridge, MA 02144
	United States of America		United States of America
	Email: krose@krose.org		Email: krose@krose.org
			Christopher A. Wood (editor)
			Apple Inc.
			One Apple Park Way
			Cupertino, California 95014
			United States of America
			Email: cawood@apple.com
End of changes. 169 change blocks.
	1208 lines changed or deleted		349 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/