draft-ietf-taps-transport-security-02.txt		draft-ietf-taps-transport-security-03.txt
	Network Working Group T. Pauly		Network Working Group T. Pauly
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Informational C. Perkins		Intended status: Informational C. Perkins
	Expires: January 1, 2019 University of Glasgow		Expires: April 25, 2019 University of Glasgow
	K. Rose		K. Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	C. Wood		C. Wood
	Apple Inc.		Apple Inc.
	June 30, 2018		October 22, 2018
	A Survey of Transport Security Protocols		A Survey of Transport Security Protocols
	draft-ietf-taps-transport-security-02		draft-ietf-taps-transport-security-03
	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 [RFC8095] by		efforts to define and catalog transport services [RFC8095] by
	describing the interfaces required to add security protocols. It		describing the interfaces required to add security protocols. It
	examines Transport Layer Security (TLS), Datagram Transport Layer		examines Transport Layer Security (TLS), Datagram Transport Layer
	Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +		Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 January 1, 2019.		This Internet-Draft will expire on April 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5		3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5
	4. Transport Security Protocol Descriptions . . . . . . . . . . 7		4. Transport Security Protocol Descriptions . . . . . . . . . . 7
	4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7		4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7
	4.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 8		4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8
	4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9		4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
	4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9		4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9
	4.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 10		4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10
	4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10		4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
	4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10		4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11
	4.3.1. Protocol Description . . . . . . . . . . . . . . . . 10		4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
	4.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 11		4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11
	4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11		4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12
	4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11		4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12
	4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12		4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
	4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12		4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12
	4.4.2. Protocol features . . . . . . . . . . . . . . . . . . 13		4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14
	4.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 14		4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14
	4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14		4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15
	4.5.1. Protocol description . . . . . . . . . . . . . . . . 14		4.5.1. Protocol description . . . . . . . . . . . . . . . . 15
	4.5.2. Protocol features . . . . . . . . . . . . . . . . . . 15		4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16
	4.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 16		4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16
	4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16		4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16
	4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16		4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16		4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17
	4.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 17		4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18
	4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18		4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
	4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18		4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.7.1. Protocol description . . . . . . . . . . . . . . . . 18		4.7.1. Protocol description . . . . . . . . . . . . . . . . 18
	4.7.2. Protocol features . . . . . . . . . . . . . . . . . . 19		4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
	4.7.3. Protocol dependencies . . . . . . . . . . . . . . . . 19		4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19
	4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19		4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19		4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
	4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20		4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20
	4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20		4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21
	4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20		4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 21
	4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20		4.9.1. Protocol Description . . . . . . . . . . . . . . . . 21
	4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22		4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22
	4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22		4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22
	5. Security Features and Transport Dependencies . . . . . . . . 22		5. Security Features and Transport Dependencies . . . . . . . . 23
	5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22		5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 23
	5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23		5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23
	5.3. Optional Feature Availability . . . . . . . . . . . . . . 25		5.3. Optional Feature Availability . . . . . . . . . . . . . . 25
	6. Transport Security Protocol Interfaces . . . . . . . . . . . 25		6. Transport Security Protocol Interfaces . . . . . . . . . . . 26
	6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26		6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26
	6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27		6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27
	6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27		6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	10. Normative References . . . . . . . . . . . . . . . . . . . . 28		10. Normative References . . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	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 [RFC8095] by		efforts to define and catalog transport services [RFC8095] by
	describing the interfaces required to add security protocols. It		describing the interfaces required to add security protocols. It
	examines Transport Layer Security (TLS), Datagram Transport Layer		examines Transport Layer Security (TLS), Datagram Transport Layer
	Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +		Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	Mandatory or Optional for an application's implementation.		Mandatory or Optional for an application's implementation.
	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. Security protocols may be used
	alongside transport protocols, and in combination with other		alongside transport protocols, and in combination with other
	security protocols when appropriate.		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 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,		o Cryptographic context: a set of cryptographic parameters,
	including but not necessarily limited to keys for encryption,		including but not necessarily limited to keys for encryption,
	authentication, and session resumption, enabling authorized		authentication, and session resumption, enabling authorized
	parties to a session to communicate securely.		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 Connection Mobility: a property of a connection that allows it to		o Connection Mobility: a property of a connection that allows it to
	be multihomed or resilient across network interface or address		be multihomed or resilient across network interface or address
	changes.		changes, e.g., 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 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. Security Features
	In this section, we enumerate Security Features exposed by protocols		In this section, we enumerate Security Features exposed by protocols
	discussed in the remainder of this document. Protocol security		discussed in the remainder of this document. Security Features
			extend the set of Transport Features described in [RFC8095] and
			provided by Transport Services implementations. Protocol security
	properties that are unrelated to the API surface exposed by such		properties that are unrelated to the API surface exposed by such
	protocols, such as client or server identity hiding, are not listed		protocols, such as client or server identity hiding, are not listed
	here as features.		here as features.
	o Forward-secure key establishment: Cryptographic key establishment		o Forward-secure key establishment: Cryptographic key establishment
	with forward secure properties.		with forward secure properties.
	o Cryptographic algorithm negotiation: Negotiate support of protocol		o Cryptographic algorithm negotiation: Negotiate support of protocol
	algorithms, including: encryption, hash, MAC (PRF), and digital		algorithms, including: encryption, hash, MAC (PRF), and digital
	signature algorithms.		signature algorithms.
	o Stateful and stateless cross-connection session resumption:		o Stateful and stateless cross-connection session resumption:
	Connection establishment without needing to complete an entirely		Connection establishment without needing to complete an entirely
	new handshake.		new handshake.
			o Session caching and management: Manage session state cache used
			for subsequent connections aimed towards amortizing connection
			establishment costs.
	o Peer authentication (certificate, raw public key, pre-shared key,		o Peer authentication (certificate, raw public key, pre-shared key,
	or EAP-based): Peer authentication using select or protocol-		or EAP-based): Peer authentication using select or protocol-
	specific mechanisms.		specific mechanisms.
	o Mutual authentication: Connection establishment wherein both		o Mutual authentication: Connection establishment wherein both
	endpoints are authenticated.		endpoints are authenticated.
			o Application-layer authentication delegation: Out-of-band peer
			authentication performed by applications outside of the connection
			establishment.
	o Record (channel or datagram) confidentiality and integrity:		o Record (channel or datagram) confidentiality and integrity:
	Encryption and authentication of application plaintext bytes sent		Encryption and authentication of application plaintext bytes sent
	between peers over a channel or in individual datagrams.		between peers over a channel or in individual datagrams.
	o Partial record confidentiality: Encryption of some portion of		o Partial record confidentiality: Encryption of some portion of
	records.		records.
	o Optional record integrity: Optional authentication of certain		o Optional record integrity: Optional authentication of certain
	records.		records.
	o Record replay prevention: Protocol detection and defense against		o Record replay prevention: Protocol detection and defense against
	record replays, e.g., due to in-network retransmissions.		record replays, e.g., due to in-network retransmissions.
	o Application-layer feature negotiation: Securely negotiate
	application-specific functionality.
	o Early data support (starting with TLS 1.3): Transmission of		o Early data support (starting with TLS 1.3): Transmission of
	application data prior to connection (handshake) establishment.		application data prior to connection (handshake) establishment.
	o Connection mobility: Connection continuation in the presence of		o Connection mobility: Connection continuation in the presence of
	5-tuple changes beneath the secure transport protocol, e.g., due		5-tuple changes beneath the secure transport protocol, e.g., due
	to NAT rebindings.		to NAT rebindings.
	o Application-layer authentication delegation: Out-of-band peer		o Application-layer feature negotiation: Securely negotiate
	authentication performed by applications outside of the connection		application-specific functionality, including those necessary for
	establishment.		connection handling and management, e.g., the TLS parent
			connection protocol type via ALPN [RFC7301] or desired application
			identity via SNI [RFC6066].
			o Configuration extensions: Add 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-		o Out-of-order record receipt: Processing of records received out-
	of-order.		of-order.
	o DoS mitigation (cookie or puzzle based): Peer DoS mitigation via		o Source validation (cookie or puzzle based): Peer source validation
	explicit proof of origin (cookie) or work mechanisms (puzzles).		and DoS mitigation via explicit proof of origin (cookie) or work
			mechanisms (puzzles).
	o Connection re-keying: In-band cryptographic handshake re-keying.		o Connection re-keying: In-band cryptographic handshake re-keying.
	o Optional length-hiding and anti-amplification padding: Protocol-		o Length-hiding padding: Protocol-drive record padding aimed at
	drive record padding aimed at hiding plaintext message length and		hiding plaintext message length and mitigating amplification
	mitigating amplification attack vectors.		attack vectors.
	4. Transport Security Protocol Descriptions		4. Transport Security Protocol Descriptions
	This section contains descriptions of security protocols currently		This section contains descriptions of security protocols currently
	used to protect data being sent over a network.		used to protect data being sent over a network.
	For each protocol, we describe its provided features and dependencies		For each protocol, we describe its provided features and dependencies
	on other protocols.		on other protocols.
	4.1. TLS		4.1. TLS
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 18 ¶
	nonce generation and encoding for each record. The record protocol		nonce generation and encoding for each record. The record protocol
	is hidden from the client behind a bytestream-oriented API.		is hidden from the client behind a bytestream-oriented API.
	The handshake protocol serves several purposes, including: peer		The handshake protocol serves several purposes, including: peer
	authentication, protocol option (key exchange algorithm and		authentication, protocol option (key exchange algorithm and
	ciphersuite) negotiation, and key derivation. Peer authentication		ciphersuite) negotiation, and key derivation. Peer authentication
	may be mutual; however, commonly, only the server is authenticated.		may be mutual; however, commonly, only the server is authenticated.
	X.509 certificates are commonly used in this authentication step,		X.509 certificates are commonly used in this authentication step,
	though other mechanisms, such as raw public keys [RFC7250], exist.		though other mechanisms, such as raw public keys [RFC7250], exist.
	The client is not authenticated unless explicitly requested by the		The client is not authenticated unless explicitly requested by the
	server with a CertificateRequest handshake message. Assuming strong		server.
	cryptography, an infrastructure for trust establishment, correctly-
	functioning endpoints, and communication patterns free from side
	channels, server authentication is sufficient to establish a channel
	resistant to eavesdroppers.
	The handshake protocol is also extensible. It allows for a variety		The handshake protocol is also extensible. It allows for a variety
	of extensions to be included by either the client or server. These		of extensions to be included by either the client or server. These
	extensions are used to specify client preferences, e.g., the		extensions are used to specify client preferences, e.g., the
	application-layer protocol to be driven with the TLS connection		application-layer protocol to be driven with the TLS connection
	[RFC7301], or signals to the server to aid operation, e.g., Server		[RFC7301], or signals to the server to aid operation, e.g., Server
	Name Indication (SNI) [RFC6066]. Various extensions also exist to		Name Indication (SNI) [RFC6066]. Various extensions also exist to
	tune the parameters of the record protocol, e.g., the maximum		tune the parameters of the record protocol, e.g., the maximum
	fragment length [RFC6066].		fragment length [RFC6066] and record size limit
			[I-D.ietf-tls-record-limit].
	Alerts are used to convey errors and other atypical events to the		Alerts are used to convey errors and other atypical events to the
	endpoints. There are two classes of alerts: closure and error		endpoints. There are two classes of alerts: closure and error
	alerts. A closure alert is used to signal to the other peer that the		alerts. A closure alert is used to signal to the other peer that the
	sender wishes to terminate the connection. The sender typically		sender wishes to terminate the connection. The sender typically
	follows a close alert with a TCP FIN segment to close the connection.		follows a close alert with a TCP FIN segment to close the connection.
	Error alerts are used to indicate problems with the handshake or		Error alerts are used to indicate problems with the handshake or
	individual records. Most errors are fatal and are followed by		individual records. Most errors are fatal and are followed by
	connection termination. However, warning alerts may be handled at		connection termination. However, warning alerts may be handled at
	the discretion of the implementation.		the discretion of the implementation.
	Once a session is disconnected all session keying material must be		Once a session is disconnected all session keying material must be
	destroyed, with the exception of secrets previously established		destroyed, with the exception of secrets previously established
	expressly for purposes of session resumption. TLS supports stateful		expressly for purposes of session resumption. TLS supports stateful
	and stateless resumption. (Here, "state" refers to bookkeeping on a		and stateless resumption. (Here, "state" refers to bookkeeping on a
	per-session basis by the server. It is assumed that the client must		per-session basis by the server. It is assumed that the client must
	always store some state information in order to resume a session.)		always store some state information in order to resume a session.)
	4.1.2. Protocol Features		4.1.2. Security Features
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Stateful and stateless cross-connection session resumption.		o Stateful and stateless cross-connection session resumption.
			o Session caching and management.
	o Peer authentication (Certificate, raw public key, and pre-shared		o Peer authentication (Certificate, raw public key, and pre-shared
	key).		key).
	o Mandatory server authentication, optional client authentication.		o Mandatory server authentication, optional client authentication.
			o Application authentication delegation.
	o Record (channel) confidentiality and integrity.		o Record (channel) confidentiality and integrity.
	o Record replay prevention.		o Record replay prevention.
	o Application-layer feature negotiation.		o Application-layer feature negotiation.
			o Configuration extensions.
	o Early data support (starting with TLS 1.3).		o Early data support (starting with TLS 1.3).
	o Optional length-hiding padding (starting with TLS 1.3).		o Optional record-layer padding (starting with TLS 1.3).
	4.1.3. Protocol Dependencies		4.1.3. Protocol Dependencies
	o TCP for in-order, reliable transport.		o TCP for in-order, reliable transport.
	o (Optionally) A PKI trust store for certificate validation.		o (Optionally) A PKI trust store for certificate validation.
	4.2. DTLS		4.2. DTLS
	DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,		DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 21 ¶
	handshake messages across records. The receiver must reassemble		handshake messages across records. The receiver must reassemble
	records before processing.		records before processing.
	DTLS relies on unique UDP 4-tuples to identify connections. Since		DTLS relies on unique UDP 4-tuples to identify connections. Since
	all application-layer data is encrypted, demultiplexing over the same		all application-layer data is encrypted, demultiplexing over the same
	4-tuple requires the use of a connection identifier extension		4-tuple requires the use of a connection identifier extension
	[I-D.ietf-tls-dtls-connection-id] to permit identification of the		[I-D.ietf-tls-dtls-connection-id] to permit identification of the
	correct connection-specific cryptographic context without the use of		correct connection-specific cryptographic context without the use of
	trial decryption. (Note that this extension is only supported in		trial decryption. (Note that this extension is only supported in
	DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.)		DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.)
	Since datagrams can be replayed, DTLS provides optional anti-replay		Since datagrams can be replayed, DTLS provides optional anti-replay
	detection based on a window of acceptable sequence numbers [RFC6347].		detection based on a window of acceptable sequence numbers [RFC6347].
	4.2.2. Protocol Features		4.2.2. Security Features
	o Record replay protection.		o Record replay protection.
	o Record (datagram) confidentiality and integrity.		o Record (datagram) confidentiality and integrity.
	o Out-of-order record receipt.		o Out-of-order record receipt.
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	See also the features from TLS.		See also the features from TLS.
	4.2.3. Protocol Dependencies		4.2.3. Protocol Dependencies
	o Since DTLS runs over an unreliable, unordered datagram transport,
	it does not require any reliability features.
	o The DTLS record protocol explicitly encodes record lengths, so		o The DTLS record protocol explicitly encodes record lengths, so
	although it runs over a datagram transport, it does not rely on		although it runs over a datagram transport, it does not rely on
	the transport protocol's framing beyond requiring transport-level		the transport protocol's framing beyond requiring transport-level
	reconstruction of datagrams fragmented over packets. (Note: DTLS		reconstruction of datagrams fragmented over packets. (Note: DTLS
	1.3 short header records omit the explicit length field.)		1.3 short header records omit the explicit length field.)
	o UDP 4-tuple uniqueness, or the connection identifier extension,		o UDP 4-tuple uniqueness, or the connection identifier extension,
	for demultiplexing.		for demultiplexing.
	o Path MTU discovery.		o Path MTU discovery.
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 32 ¶
	o Starting the handshake to generate keys and provide authentication		o Starting the handshake to generate keys and provide authentication
	(and providing the transport for the handshake).		(and providing the transport for the handshake).
	o Client address validation.		o Client address validation.
	o Key ready events from TLS to notify the QUIC transport.		o Key ready events from TLS to notify the QUIC transport.
	o Exporting secrets from TLS to the QUIC transport.		o Exporting secrets from TLS to the QUIC transport.
	The QUIC transport layer support multiple streams over a single		The QUIC transport layer support multiple streams over a single
	connection. The first stream is reserved specifically for a TLS		connection. QUIC implements a record protocol for TLS handshake
	connection. The TLS handshake, along with further records, are sent		messages to establish a connection. These messages are sent in
	over this stream. This TLS connection follows the TLS standards and		special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of
	inherits the security properties of TLS. The handshake generates		which are encrypted using different keys. INITIAL frames are
	keys, which are then exported to the rest of the QUIC connection, and		encrypted using "fixed" keys derived from the QUIC version and public
	are used to protect the rest of the streams.		packet information (Connection ID). CRYPTO frames are encrypted
			using TLS handshake secrets. Once TLS completes, QUIC uses the
	Initial QUIC messages (packets) are encrypted using "fixed" keys		resultant traffic secrets to for the QUIC connection to protect the
	derived from the QUIC version and public packet information		rest of the streams. QUIC supports 0-RTT (early) data using
	(Connection ID). Packets are later encrypted using keys derived from		previously negotiated connection secrets. Early data is sent in
	the TLS traffic secret upon handshake completion. The TLS 1.3		0-RTT packets, which may be included in the same datagram as the
	handshake for QUIC is used in either a single-RTT mode or a fast-open		Initial and Handshake packets.
	zero-RTT mode. When zero-RTT handshakes are possible, the encryption
	first transitions to use the zero-RTT keys before using single-RTT
	handshake keys after the next TLS flight.
	4.3.2. Protocol Features		4.3.2. Security Features
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	See also the properties of TLS.		See also the properties of TLS.
	4.3.3. Protocol Dependencies		4.3.3. Protocol Dependencies
	o QUIC transport relies on UDP.		o QUIC transport relies on UDP.
	o QUIC transport relies on TLS 1.3 for peer authentication and		o QUIC transport relies on TLS 1.3 for key exchange, peer
	initial key derivation.		authentication, and shared secret derivation.
	o TLS within QUIC relies on QUIC for reliable handshake record
	transmission and receipt.
	4.3.4. Variant: Google QUIC		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		4.4. IKEv2 with ESP
	IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec		IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
	protocol suite that encrypts and authenticates IP packets, either as		protocol suite that encrypts and authenticates IP packets, either for
	for creating tunnels (tunnel-mode) or for direct transport		creating tunnels (tunnel-mode) or for direct transport connections
	connections (transport-mode). This suite of protocols separates out		(transport-mode). This suite of protocols separates out the key
	the key generation protocol (IKEv2) from the transport encryption		generation protocol (IKEv2) from the transport encryption protocol
	protocol (ESP). Each protocol can be used independently, but this		(ESP). Each protocol can be used independently, but this document
	document considers them together, since that is the most common		considers them together, since that is the most common pattern.
	pattern.
	4.4.1. Protocol descriptions		4.4.1. Protocol descriptions
	4.4.1.1. IKEv2		4.4.1.1. IKEv2
	IKEv2 is a control protocol that runs on UDP port 500. Its primary		IKEv2 is a control protocol that runs on UDP port 500. Its primary
	goal is to generate keys for Security Associations (SAs). An SA		goal is to generate keys for Security Associations (SAs). An SA
	contains shared (cryptographic) information used for establishing		contains shared (cryptographic) information used for establishing
	other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a		other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a
	Diffie-Hellman key exchange to generate keys for the "IKE SA", which		Diffie-Hellman key exchange to generate keys for the "IKE SA", which
	skipping to change at page 13, line 39 ¶		skipping to change at page 14, line 5 ¶
	Since ESP operates on IP packets, it is not directly tied to the		Since ESP operates on IP packets, it is not directly tied to the
	transport protocols it encrypts. This means it requires little or no		transport protocols it encrypts. This means it requires little or no
	change from transports in order to provide security.		change from transports in order to provide security.
	ESP packets may be sent directly over IP, but where network		ESP packets may be sent directly over IP, but where network
	conditions warrant (e.g., when a NAT is present or when a firewall		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		blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP
	[RFC8229].		[RFC8229].
	4.4.2. Protocol features		4.4.2. Security Features
	4.4.2.1. IKEv2		4.4.2.1. IKEv2
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Peer authentication (Certificate, raw public key, pre-shared key,		o Peer authentication (Certificate, raw public key, pre-shared key,
	and EAP).		and EAP).
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 32 ¶
	o Connection mobility.		o Connection mobility.
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	4.4.2.2. ESP		4.4.2.2. ESP
	o Record confidentiality and integrity.		o Record confidentiality and integrity.
	o Record replay protection.		o Record replay protection.
	4.4.3. Protocol dependencies		4.4.3. Protocol Dependencies
	4.4.3.1. IKEv2		4.4.3.1. IKEv2
	o Availability of UDP to negotiate, or implementation support for		o Availability of UDP to negotiate, or implementation support for
	TCP-encapsulation.		TCP-encapsulation.
	o Some EAP authentication types require accessing a hardware device,		o Some EAP authentication types require accessing a hardware device,
	such as a SIM card; or interacting with a user, such as password		such as a SIM card; or interacting with a user, such as password
	prompting.		prompting.
	skipping to change at page 15, line 42 ¶		skipping to change at page 16, line 12 ¶
	fingerprints are included in the signalling exchange (e.g., in SIP or		fingerprints are included in the signalling exchange (e.g., in SIP or
	WebRTC), and used to bind the DTLS key exchange in the media plane to		WebRTC), and used to bind the DTLS key exchange in the media plane to
	the signaling plane. The combination of a mutually authenticated		the signaling plane. The combination of a mutually authenticated
	DTLS key exchange on the media path and a fingerprint sent in the		DTLS key exchange on the media path and a fingerprint sent in the
	signalling channel protects against active attacks on the media,		signalling channel protects against active attacks on the media,
	provided the signalling can be trusted. Signalling needs to be		provided the signalling can be trusted. Signalling needs to be
	protected as described in, for example, SIP [RFC3261] Authenticated		protected as described in, for example, SIP [RFC3261] Authenticated
	Identity Management [RFC4474] or the WebRTC security architecture		Identity Management [RFC4474] or the WebRTC security architecture
	[I-D.ietf-rtcweb-security-arch], to provide complete system security.		[I-D.ietf-rtcweb-security-arch], to provide complete system security.
	4.5.2. Protocol features		4.5.2. Security Features
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Mutual authentication.		o Mutual authentication.
	o Partial datagram confidentiality. (Packet headers are not		o Partial datagram confidentiality. (Packet headers are not
	encrypted.)		encrypted.)
	o Optional authentication of data packets.		o Optional authentication of data packets.
	o Mandatory authentication of control packets.		o Mandatory authentication of control packets.
	o Out-of-order record receipt.		o Out-of-order record receipt.
	4.5.3. Protocol dependencies		4.5.3. Protocol Dependencies
	o External key derivation and management protocol, e.g., DTLS		o External key derivation and management protocol, e.g., DTLS
	[RFC5763].		[RFC5763].
	o External identity management protocol, e.g., SIP Authenticated		o External identity management protocol, e.g., SIP Authenticated
	Identity Management [RFC4474], WebRTC Security Architecture		Identity Management [RFC4474], WebRTC Security Architecture
	[I-D.ietf-rtcweb-security-arch].		[I-D.ietf-rtcweb-security-arch].
	4.5.4. Variant: ZRTP for Media Path Key Agreement		4.5.4. Variant: ZRTP for Media Path Key Agreement
	skipping to change at page 17, line 40 ¶		skipping to change at page 18, line 13 ¶
	resumption across a pool of servers implies shared state.		resumption across a pool of servers implies shared state.
	Owing to middlebox ossification issues, tcpcrypt only protects the		Owing to middlebox ossification issues, tcpcrypt only protects the
	payload portion of a TCP packet. It does not encrypt any header		payload portion of a TCP packet. It does not encrypt any header
	information, such as the TCP sequence number.		information, such as the TCP sequence number.
	Tcpcrypt exposes a universally-unique connection-specific session ID		Tcpcrypt exposes a universally-unique connection-specific session ID
	to the application, suitable for application-level endpoint		to the application, suitable for application-level endpoint
	authentication either in-band or out-of-band.		authentication either in-band or out-of-band.
	4.6.2. Protocol Features		4.6.2. Security Features
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o Record (channel) confidentiality and integrity.		o Record (channel) confidentiality and integrity.
	o Stateful cross-connection session resumption.		o Stateful cross-connection session resumption.
			o Session caching and management.
	o Connection re-keying.		o Connection re-keying.
	o Application authentication delegation.		o Application authentication delegation.
	4.6.3. Protocol Dependencies		4.6.3. Protocol Dependencies
	o TCP		o TCP.
	o TCP Encryption Negotiation Option (ENO)		o TCP Encryption Negotiation Option (ENO).
	4.7. WireGuard		4.7. WireGuard
	WireGuard is a layer 3 protocol designed to complement or replace		WireGuard is a layer 3 protocol designed to complement or replace
	IPsec [WireGuard]. Unlike most transport security protocols, which		IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate
	rely on PKI for peer authentication, WireGuard authenticates peers		IP datagrams between peers. Unlike most transport security
	using pre-shared public keys delivered out-of-band, each of which is		protocols, which rely on PKI for peer authentication, WireGuard
	bound to one or more IP addresses. Moreover, as a protocol suited		authenticates peers using pre-shared public keys delivered out-of-
	for VPNs, WireGuard offers no extensibility, negotiation, or		band, each of which is bound to one or more IP addresses. Moreover,
	cryptographic agility.		as a protocol suited for VPNs, WireGuard offers no extensibility,
			negotiation, or cryptographic agility.
	4.7.1. Protocol description		4.7.1. Protocol description
	WireGuard is a simple VPN protocol that binds a pre-shared public key		WireGuard is a simple VPN protocol that binds a pre-shared public key
	to one or more IP addresses. Users configure WireGuard by		to one or more IP addresses. Users configure WireGuard by
	associating peer public keys with IP addresses. These mappings are		associating peer public keys with IP addresses. These mappings are
	stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]		stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]
	for more details and sample configurations.) These keys are used		for more details and sample configurations.) These keys are used
	upon WireGuard packet transmission and reception. For example, upon		upon WireGuard packet transmission and reception. For example, upon
	receipt of a Handshake Initiation message, receivers use the static		receipt of a Handshake Initiation message, receivers use the static
	skipping to change at page 19, line 8 ¶		skipping to change at page 19, line 31 ¶
	introduced.		introduced.
	WireGuard is designed to be entirely stateless, modulo the CryptoKey		WireGuard is designed to be entirely stateless, modulo the CryptoKey
	routing table, which has size linear with the number of trusted		routing table, which has size linear with the number of trusted
	peers. If a WireGuard receiver is under heavy load and cannot		peers. If a WireGuard receiver is under heavy load and cannot
	process a packet, e.g., cannot spare CPU cycles for point		process a packet, e.g., cannot spare CPU cycles for point
	multiplication, it can reply with a cookie similar to DTLS and IKEv2.		multiplication, it can reply with a cookie similar to DTLS and IKEv2.
	This cookie only proves IP address ownership. Any rate limiting		This cookie only proves IP address ownership. Any rate limiting
	scheme can be applied to packets coming from non-spoofed addresses.		scheme can be applied to packets coming from non-spoofed addresses.
	4.7.2. Protocol features		4.7.2. Security Features
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o Peer authentication (Public-key and PSK).		o Peer authentication (Public-key and PSK).
	o Mutual authentication.		o Mutual authentication.
	o Record replay prevention (Stateful, timestamp-based).		o Record replay prevention (Stateful, timestamp-based).
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	4.7.3. Protocol dependencies		4.7.3. Protocol Dependencies
	o Datagram transport.		o Datagram transport.
	o Out-of-band key distribution and management.		o Out-of-band key distribution and management.
	4.8. MinimalT		4.8. MinimalT
	MinimalT is a UDP-based transport security protocol designed to offer		MinimalT is a UDP-based transport security protocol designed to offer
	confidentiality, mutual authentication, DoS prevention, and		confidentiality, mutual authentication, DoS prevention, and
	connection mobility [MinimalT]. One major goal of the protocol is to		connection mobility [MinimalT]. One major goal of the protocol is to
	skipping to change at page 20, line 24 ¶		skipping to change at page 20, line 51 ¶
	(server) can verify the authenticity of the request and derive a		(server) can verify the authenticity of the request and derive a
	shared secret. Within a tunnel, new connections to services may be		shared secret. Within a tunnel, new connections to services may be
	established.		established.
	4.8.2. Protocol Features		4.8.2. Protocol Features
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o DoS mitigation (puzzle-based).		o DoS mitigation (puzzle-based).
	o Connection mobility (tunnel-based).		o Connection mobility (based on tunnel identifiers).
	Additional (orthogonal) transport features include: connection		Additional (orthogonal) transport features include: connection
	multiplexing between hosts across shared tunnels, and congestion		multiplexing between hosts across shared tunnels, and congestion
	control state is shared across connections between the same host		control state is shared across connections between the same host
	pairs.		pairs.
	4.8.3. Protocol Dependencies		4.8.3. Protocol Dependencies
	o A DNS-like resolution service to obtain location information (an		o A DNS-like resolution service to obtain location information (an
	IP address) and ephemeral keys.		IP address) and ephemeral keys.
	skipping to change at page 21, line 37 ¶		skipping to change at page 22, line 15 ¶
	given the risk of long-term private key compromise.		given the risk of long-term private key compromise.
	The client and server do not perform a standard key exchange.		The client and server do not perform a standard key exchange.
	Instead, in the initial exchange of packets, each party provides its		Instead, in the initial exchange of packets, each party provides its
	own ephemeral key to the other end. The client can choose a new		own ephemeral key to the other end. The client can choose a new
	ephemeral key for every new connection. However, the server must		ephemeral key for every new connection. However, the server must
	rotate these keys on a slower basis. Otherwise, it would be trivial		rotate these keys on a slower basis. Otherwise, it would be trivial
	for an attacker to force the server to create and store ephemeral		for an attacker to force the server to create and store ephemeral
	keys with a fake client initialization packet.		keys with a fake client initialization packet.
	Unlike TCP, the server employs cookies to enable source validation.		Servers use cookies for source validation. After receiving a
	After receiving the client's initial packet, encrypted under the		client's initial packet, encrypted under the server's long-term
	server's long-term public key, the server generates and returns a		public key, a server generates and returns a stateless cookie that
	stateless cookie that must be echoed back in the client's following		must be echoed back in the client's following message. This cookie
	message. This cookie is encrypted under the client's ephemeral		is encrypted under the client's ephemeral public key. This stateless
	public key. This stateless technique prevents attackers from		technique prevents attackers from hijacking client initialization
	hijacking client initialization packets to obtain cookie values to		packets to obtain cookie values to flood clients. (A client would
	flood clients. (A client would detect the duplicate cookies and		detect the duplicate cookies and reject the flooded packets.)
	reject the flooded packets.) Similarly, replaying the client's		Similarly, replaying the client's second packet, carrying the cookie,
	second packet, carrying the cookie, will be detected by the server.		will be detected by the server.
	CurveCP supports a weak form of client authentication. Clients are		CurveCP supports a weak form of client authentication. Clients are
	permitted to send their long-term public keys in the second		permitted to send their long-term public keys in the second
	initialization packet. A server can verify this public key and, if		initialization packet. A server can verify this public key and, if
	untrusted, drop the connection and subsequent data.		untrusted, drop the connection and subsequent data.
	Unlike some other protocols, CurveCP data packets leave only the		Unlike some other protocols, CurveCP data packets leave only the
	ephemeral public key, the connection ID, and the per-message nonce in		ephemeral public key, the connection ID, and the per-message nonce in
	the clear. Everything else is encrypted.		the clear. Everything else is encrypted.
	4.9.2. Protocol Features		4.9.2. Protocol Features
	o Datagram confidentiality and integrity (via public key		o Datagram confidentiality and integrity (via public key
	encryption).		encryption).
	o 1-RTT session bootstrapping.
	o Connection mobility (based on a client-chosen ephemeral		o Connection mobility (based on a client-chosen ephemeral
	identifier).		identifier).
	o Optional length-hiding and anti-amplification padding.		o Optional length-hiding and anti-amplification padding.
	4.9.3. Protocol Dependencies		4.9.3. Protocol Dependencies
	o An unreliable transport protocol such as UDP.		o An unreliable transport protocol such as UDP.
	5. Security Features and Transport Dependencies		5. Security Features and Transport Dependencies
	There exists a common set of features shared across the transport		There exists a common set of features shared across the transport
	protocols surveyed in this document. Mandatory features constitute a		protocols surveyed in this document. Mandatory features constitute a
	baseline of functionality that an application may assume for any TAPS		baseline of functionality that an application may assume for any TAPS
	implementation. Optional features by contrast may vary from		implementation. They were selected on the basis that they are either
	implementation to implementation, and so an application cannot simply		(a) required for any secure transport protocol or (b) nearly
	assume they are available. Applications learn of and use optional		ubiquitous amongst common secure transport protocols. Optional
	features by querying for their presence and support. Optional		features by contrast may vary from implementation to implementation,
	features may not be implemented, or may be disabled if their presence		and so an application cannot simply assume they are available.
	impacts transport services or if a necessary transport service is		Applications learn of and use optional features by querying for their
	unavailable.		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 is unavailable.
	5.1. Mandatory Features		5.1. Mandatory Features
	o Segment or datagram encryption and authentication: Transit data		o Segment or datagram encryption and authentication: Protect transit
	must be protected with an authenticated encryption algorithm.		data with an authenticated encryption algorithm.
	o Forward-secure key establishment: Negotiated keying material must		o Forward-secure key establishment.
	come from an authenticated, forward-secure key exchange protocol.
	o Public-key (raw or certificate) based authentication:		o Public-key (raw or certificate) based authentication.
	Authentication based on public key signatures is commonplace for
	many transport security protocols.
	o Responder authentication: The endpoint (receiver) of a new		o Unilateral responder authentication.
	connection must be authenticated before any data is sent to said
	party.
	o Pre-shared key support: A security protocol must be able to use a		o Pre-shared key support.
	pre-shared key established out-of-band or from a prior session to
	encrypt individual messages, packets, or datagrams.
	5.2. Optional Features		5.2. Optional Features
	o Cryptographic algorithm negotiation (AN): Transport security		o Cryptographic algorithm negotiation (AN):
	protocols should permit applications to configure supported or
	enabled cryptographic algorithms.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: Application awareness of supported or		* Application dependency: Application awareness of supported or
	desired algorithms.		desired algorithms.
	o Application authentication delegation (AD): Some protocols may		o Application authentication delegation (AD):
	completely defer endpoint authentication to applications, e.g., to
	reduce online protocol complexity.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: Application opt-in and policy for		* Application dependency: Application opt-in and policy for
	endpoint authentication		endpoint authentication
	o Mutual authentication (MA): Transport security protocols should		o Mutual authentication (MA):
	allow each endpoint to authenticate the other if required by the
	application.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: Mutual authentication required for		* Application dependency: Mutual authentication required for
	application support.		application support.
	o DoS mitigation (DM): Transport security protocols may need to		o DoS mitigation (DM):
	support volumetric DoS prevention via, e.g., cookies or initiator-
	side puzzles.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: None.		* Application dependency: None.
	o Connection mobility (CM): Sessions should not be bound to a		o Connection mobility (CM):
	network connection (or 5-tuple). This allows cryptographic key
	material and other state information to be reused in the event of
	a connection change. Examples of this include a NAT rebinding
	that occurs without a client's knowledge.
	* Transport dependency: Connections are unreliable or can change		* Transport dependency: Connections are unreliable or can change
	due to unpredictable network events, e.g., NAT re-bindings.		due to unpredictable network events, e.g., NAT re-bindings.
	* Application dependency: None.		* Application dependency: None.
	o Source validation (SV): Source validation must be provided to		o Source validation (SV):
	mitigate server-targeted DoS attacks. This can be done with
	puzzles or cookies.
	* Transport dependency: Packets may arrive as datagrams instead		* Transport dependency: Packets may arrive as datagrams instead
	of streams from unauthenticated sources.		of streams from unauthenticated sources.
	* Application dependency: None.		* Application dependency: None.
	o Application-layer feature negotiation (AFN): The type of		o Application-layer feature negotiation (AFN):
	application using a transport security protocol often requires
	features configured at the connection establishment layer, e.g.,
	ALPN [RFC7301]. Moreover, application-layer features may often be
	used to offload the session to another server which can better
	handle the request. (The TLS SNI is one example of such a
	feature.) As such, transport security protocols should provide a
	generic mechanism to allow for such application-specific features
	and options to be configured or otherwise negotiated.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: Specification of application-layer		* Application dependency: Specification of application-layer
	features or functionality.		features or functionality.
	o Configuration extensions (CX): The protocol negotiation should be		o Configuration extensions (CX):
	extensible with addition of new configuration options.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: Specification of application-specific		* Application dependency: Specification of application-specific
	extensions.		extensions.
	o Session caching and management (SC): Sessions should be cacheable		o Session caching and management (SC):
	to enable reuse and amortize the cost of performing session
	establishment handshakes.
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: None.		* Application dependency: None.
	o Length-hiding padding (LHP): Applications may wish to defer		o Early data support (ED):
	traffic padding to the security protocol to deter traffic analysis
	attacks.		* Transport dependency: None.
			* Application dependency: Anti-replay protections or hints of
			data idempotency.
			o Length-hiding padding (LHP):
	* Transport dependency: None.		* Transport dependency: None.
	* Application dependency: Knowledge of desired padding policies.		* Application dependency: Knowledge of desired padding policies.
	5.3. Optional Feature Availability		5.3. Optional Feature Availability
	The following table lists the availability of the above-listed		The following table lists the availability of the above-listed
	optional features in each of the analyzed protocols. "Mandatory"		optional features in each of the analyzed protocols. "Mandatory"
	indicates that the feature is intrinsic to the protocol and cannot be		indicates that the feature is intrinsic to the protocol and cannot be
	disabled. "Supported" indicates that the feature is optionally		disabled. "Supported" indicates that the feature is optionally
	provided natively or through a (standardized, where applicable)		provided natively or through a (standardized, where applicable)
	extension.		extension.
	+-----------+----+----+----+-----+----+----+-----+----+----+-----+		+----------+---+----+----+-----+----+----+-----+----+----+-----+----+
	| Protocol | AN | AD | MA | DM | CM | SV | AFN | CX | SC | LHP |		| Protocol | A | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | ED |
	+-----------+----+----+----+-----+----+----+-----+----+----+-----+		| | N | | | | | | | | | | |
	| TLS | S | S | S | S | U* | M | S | S | S | S |		+----------+---+----+----+-----+----+----+-----+----+----+-----+----+
	| | | | | | | | | | | |		| TLS | S | S | S | S | U* | M | S | S | S | S | S |
	| DTLS | S | S | S | S | S | M | S | S | S | S |		| | | | | | | | | | | | |
	| | | | | | | | | | | |		| DTLS | S | S | S | S | S | M | S | S | S | S | U |
	| IETF QUIC | S | S | S | S | S | M | S | S | S | S |		| | | | | | | | | | | | |
	| | | | | | | | | | | |		| IETF | S | S | S | S | S | M | S | S | S | S | S |
	| IKEv2+ESP | S | S | M | S | S | M | S | S | S | S |		| QUIC | | | | | | | | | | | |
	| | | | | | | | | | | |		| | | | | | | | | | | | |
	| SRTP+DTLS | S | S | S | S | U | M | S | S | S | U |		| IKEv2+ES | S | S | M | S | S | M | S | S | S | S | U |
	| | | | | | | | | | | |		| P | | | | | | | | | | | |
	| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U |		| | | | | | | | | | | | |
	| | | | | | | | | | | |		| SRTP+DTL | S | S | S | S | U | M | S | S | S | U | U |
	| WireGuard | U | S | M | S | U | M | U | U | U | S+ |		| S | | | | | | | | | | | |
	| | | | | | | | | | | |		| | | | | | | | | | | | |
	| MinimalT | U | U | M | S | M | M | U | U | U | S |		| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | U |
	| | | | | | | | | | | |		| | | | | | | | | | | | |
	| CurveCP | U | U | S | S | M | M | U | U | U | S |		| WireGuar | U | S | M | S | U | M | U | U | U | S+ | U |
	+-----------+----+----+----+-----+----+----+-----+----+----+-----+		| d | | | | | | | | | | | |
			| | | | | | | | | | | | |
			| MinimalT | U | U | M | S | M | M | U | U | U | S | U |
			| | | | | | | | | | | | |
			| CurveCP | U | U | S | S | M | M | U | U | U | S | U |
			+----------+---+----+----+-----+----+----+-----+----+----+-----+----+
	M=Mandatory		M=Mandatory S=Supported but not required U=Unsupported *=On TCP;
	S=Supported but not required		MPTCP would provide this ability **=TCP provides SYN cookies
	U=Unsupported		natively, but these are not cryptographically strong +=For transport
	*=On TCP; MPTCP would provide this ability		packets only
	**=TCP provides SYN cookies natively, but these are not
	cryptographically strong
	+=For transport packets only
	6. Transport Security Protocol Interfaces		6. Transport Security Protocol Interfaces
	This section describes the interface surface exposed by the security		This section describes the interface surface exposed by the security
	protocols described above. Note that not all protocols support each		protocols described above. Note that not all protocols support each
	interface. We partition these interfaces into pre-connection		interface. We partition these interfaces into pre-connection
	(configuration), connection, and post-connection interfaces.		(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		6.1. Pre-Connection Interfaces
	Configuration interfaces are used to configure the security protocols		Configuration interfaces are used to configure the security protocols
	before a handshake begins or the keys are negotiated.		before a handshake begins or the keys are negotiated.
	o Identity and Private Keys		o Identity and Private Keys The application can provide its
	The application can provide its identities (certificates) and		identities (certificates) and private keys, or mechanisms to
	private keys, or mechanisms to access these, to the security		access these, to the security protocol to use during handshakes.
	protocol to use during handshakes.
	Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2,		Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2,
	WireGuard, SRTP		WireGuard, SRTP
	o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)		o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
	The application can choose the algorithms that are supported for		The application can choose the algorithms that are supported for
	key exchange, signatures, and ciphersuites.		key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS,
	Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP		QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP
	o Session Cache Management The application provides the ability to		o Session Cache Management The application provides the ability to
	save and retrieve session state (such as tickets, keying material,		save and retrieve session state (such as tickets, keying material,
	and server parameters) that may be used to resume the security		and server parameters) that may be used to resume the security
	session.		session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT
	Protocols: TLS, DTLS, QUIC + TLS, MinimalT
	o Authentication Delegation		o Authentication Delegation The application provides access to a
	The application provides access to a separate module that will		separate module that will provide authentication, using EAP for
	provide authentication, using EAP for example.		example. Protocols: IKEv2, SRTP
	Protocols: IKEv2, SRTP
	o Pre-Shared Key Import		o Pre-Shared Key Import Either the handshake protocol or the
	Either the handshake protocol or the application directly can		application directly can supply pre-shared keys for the record
	supply pre-shared keys for the record protocol use for encryption/		protocol use for encryption/decryption and authentication. If the
	decryption and authentication. If the application can supply keys		application can supply keys directly, this is considered explicit
	directly, this is considered explicit import; if the handshake		import; if the handshake protocol traditionally provides the keys
	protocol traditionally provides the keys directly, it is		directly, it is considered direct import; if the keys can only be
	considered direct import; if the keys can only be shared by the		shared by the handshake, they are considered non-importable.
	handshake, they are considered non-importable.
	* Explict import: QUIC, ESP		* Explict import: QUIC, ESP
	* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard		* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard
	* Non-importable: CurveCP		* Non-importable: CurveCP
	6.2. Connection Interfaces		6.2. Connection Interfaces
	o Identity Validation		o Identity Validation During a handshake, the security protocol will
	During a handshake, the security protocol will conduct identity		conduct identity validation of the peer. This can call into the
	validation of the peer. This can call into the application to		application to offload validation. Protocols: All (TLS, DTLS,
	offload validation. Protocols: All (TLS, DTLS, QUIC + TLS,		QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
	MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
	o Source Address Validation		o Source Address Validation The handshake protocol may delegate
	The handshake protocol may delegate validation of the remote peer		validation of the remote peer that has sent data to the transport
	that has sent data to the transport protocol or application. This		protocol or application. This involves sending a cookie exchange
	involves sending a cookie exchange to avoid DoS attacks.		to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
	Protocols: QUIC + TLS, DTLS, WireGuard
	6.3. Post-Connection Interfaces		6.3. Post-Connection Interfaces
	o Connection Termination The security protocol may be instructed to		o Connection Termination The security protocol may be instructed to
	tear down its connection and session information. This is needed		tear down its connection and session information. This is needed
	by some protocols to prevent application data truncation attacks.		by some protocols to prevent application data truncation attacks.
	Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2		Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2
	o Key Update		o Key Update The handshake protocol may be instructed to update its
	The handshake protocol may be instructed to update its keying		keying material, either by the application directly or by the
	material, either by the application directly or by the record		record protocol sending a key expiration event. Protocols: TLS,
	protocol sending a key expiration event.		DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2
	Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2
	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), tcpcrypt, IKEv2, DTLS (for
	SRTP)		SRTP)
	* Direct export: TLS, DTLS, MinimalT		* Direct export: TLS, DTLS, MinimalT
	* Non-exportable: CurveCP		* Non-exportable: CurveCP
	o Key Expiration		o Key Expiration The record protocol can signal that its keys are
	The record protocol can signal that its keys are expiring due to		expiring due to reaching a time-based deadline, or a use-based
	reaching a time-based deadline, or a use-based deadline (number of		deadline (number of bytes that have been encrypted with the key).
	bytes that have been encrypted with the key). This interaction is		This interaction is often limited to signaling between the record
	often limited to signaling between the record layer and the		layer and the handshake layer. Protocols: ESP ((Editor's note:
	handshake layer.		One may consider TLS/DTLS to also have this interface))
	Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also
	have this interface))
	o Connection mobility		o Connection mobility The record protocol can be signaled that it is
	The record protocol can be signaled that it is being migrated to		being migrated to another transport or interface due to connection
	another transport or interface due to connection mobility, which		mobility, which may reset address and state validation.
	may reset address and state validation.
	Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming)		Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming)
	7. IANA Considerations		7. IANA Considerations
	This document has no request to IANA.		This document has no request to IANA.
	8. Security Considerations		8. 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
	skipping to change at page 28, line 49 ¶		skipping to change at page 28, line 45 ¶
	[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..		[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..
	[Curve25519]		[Curve25519]
	"Curve25519 - new Diffie-Hellman speed records", n.d..		"Curve25519 - new Diffie-Hellman speed records", n.d..
	[CurveCP] "CurveCP -- Usable security for the Internet", n.d..		[CurveCP] "CurveCP -- Usable security for the Internet", n.d..
	[I-D.ietf-quic-tls]		[I-D.ietf-quic-tls]
	Thomson, M. and S. Turner, "Using Transport Layer Security		Thomson, M. and S. Turner, "Using Transport Layer Security
	(TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in		(TLS) to Secure QUIC", draft-ietf-quic-tls-15 (work in
	progress), June 2018.		progress), October 2018.
	[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-13 (work		and Secure Transport", draft-ietf-quic-transport-15 (work
	in progress), June 2018.		in progress), October 2018.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-14 (work in progress), March 2018.		rtcweb-security-arch-15 (work in progress), July 2018.
	[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-00 (work in		Transport Services", draft-ietf-taps-arch-02 (work in
	progress), April 2018.		progress), October 2018.
			[I-D.ietf-taps-interface]
			Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
			Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
			Abstract Application Layer Interface to Transport
			Services", draft-ietf-taps-interface-02 (work in
			progress), October 2018.
	[I-D.ietf-tcpinc-tcpcrypt]		[I-D.ietf-tcpinc-tcpcrypt]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		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)", draft-ietf-tcpinc-tcpcrypt-12 (work in		(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-13 (work in
	progress), June 2018.		progress), September 2018.
	[I-D.ietf-tcpinc-tcpeno]		[I-D.ietf-tcpinc-tcpeno]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.		Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
	Smith, "TCP-ENO: Encryption Negotiation Option", draft-		Smith, "TCP-ENO: Encryption Negotiation Option", draft-
	ietf-tcpinc-tcpeno-19 (work in progress), June 2018.		ietf-tcpinc-tcpeno-19 (work in progress), June 2018.
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,		Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
	"The Datagram Transport Layer Security (DTLS) Connection		"The Datagram Transport Layer Security (DTLS) Connection
	Identifier", draft-ietf-tls-dtls-connection-id-00 (work in		Identifier", draft-ietf-tls-dtls-connection-id-01 (work in
	progress), December 2017.		progress), July 2018.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-26 (work in progress), March		1.3", draft-ietf-tls-dtls13-28 (work in progress), July
	2018.		2018.
			[I-D.ietf-tls-record-limit]
			Thomson, M., "Record Size Limit Extension for Transport
			Layer Security (TLS)", draft-ietf-tls-record-limit-03
			(work in progress), May 2018.
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),		Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
	March 2018.		March 2018.
	[MinimalT]		[MinimalT]
	"MinimaLT -- Minimal-latency Networking Through Better		"MinimaLT -- Minimal-latency Networking Through Better
	Security", n.d..		Security", n.d..
	[Noise] "The Noise Protocol Framework", n.d..		[Noise] "The Noise Protocol Framework", n.d..
End of changes. 89 change blocks.
	259 lines changed or deleted		252 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/