draft-ietf-taps-transport-security-03.txt		draft-ietf-taps-transport-security-04.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: April 25, 2019 University of Glasgow		Expires: May 9, 2019 University of Glasgow
	K. Rose		K. Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	C. Wood		C. Wood
	Apple Inc.		Apple Inc.
	October 22, 2018		November 05, 2018
	A Survey of Transport Security Protocols		A Survey of Transport Security Protocols
	draft-ietf-taps-transport-security-03		draft-ietf-taps-transport-security-04
	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 39 ¶		skipping to change at page 1, line 39 ¶
	superset of features a TAPS system may need to support.		superset of features a TAPS system may need to support.
	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 http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 25, 2019.		This Internet-Draft will expire on May 9, 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		(http://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
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	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. Security 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. Security 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 . . . . . . . . . . . . . . . . . . 11		4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10
	4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11		4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
	4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11		4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11
	4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12		4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11
	4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12		4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11
	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. Security Features . . . . . . . . . . . . . . . . . . 14		4.4.2. Security Features . . . . . . . . . . . . . . . . . . 13
	4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14		4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14
	4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15		4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14
	4.5.1. Protocol description . . . . . . . . . . . . . . . . 15		4.5.1. Protocol description . . . . . . . . . . . . . . . . 14
	4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16		4.5.2. Security Features . . . . . . . . . . . . . . . . . . 15
	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 . . . . . . . . . . . . . . . . . . . . . . . . 17		4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17		4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16
	4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18		4.6.2. Security Features . . . . . . . . . . . . . . . . . . 17
	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. Security Features . . . . . . . . . . . . . . . . . . 19		4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
	4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19		4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19
	4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 20		4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19
	4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20		4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19
	4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20		4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20
	4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21		4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20
	4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 21		4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.9.1. Protocol Description . . . . . . . . . . . . . . . . 21		4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20
	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 . . . . . . . . 23		5. Security Features and Transport Dependencies . . . . . . . . 22
	5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 23		5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22
	5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23		5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23
	5.3. Optional Feature Availability . . . . . . . . . . . . . . 25		5.3. Optional Feature Availability . . . . . . . . . . . . . . 24
	6. Transport Security Protocol Interfaces . . . . . . . . . . . 26		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. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
	10. Normative References . . . . . . . . . . . . . . . . . . . . 28		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
			11. Normative References . . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		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
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 5 ¶
	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		o Security Feature: a feature that a network security layer provides
	to applications. Examples include authentication, encryption, key		to applications. Examples include authentication, encryption, key
	generation, session resumption, and privacy. Features may be		generation, session resumption, and privacy. Features may be
	Mandatory or Optional for an application's implementation.		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. 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: Framed protocol messages.
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 34 ¶
	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
	be multihomed or resilient across network interface or address
	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. Security Features		discussed in the remainder of this document. Protocol security (and
	extend the set of Transport Features described in [RFC8095] and		privacy) properties that are unrelated to the API surface exposed by
	provided by Transport Services implementations. Protocol security		such protocols, such as client or server identity hiding, are not
	properties that are unrelated to the API surface exposed by such		listed here as features.
	protocols, such as client or server identity hiding, are not listed
	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:
	Connection establishment without needing to complete an entirely
	new handshake.
	o Session caching and management: Manage session state cache used		o Session caching and management: Manage session state cache used
	for subsequent connections aimed towards amortizing connection		for subsequent connections aimed towards amortizing connection
	establishment costs.		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.
	skipping to change at page 6, line 49 ¶		skipping to change at page 6, line 40 ¶
	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 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: a property of a connection that allows it to
	5-tuple changes beneath the secure transport protocol, e.g., due		be multihomed or resilient across network interface or address
	to NAT rebindings.		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 Application-layer feature negotiation: Securely negotiate		o Application-layer feature negotiation: Securely negotiate
	application-specific functionality, including those necessary for		application-specific functionality, including those necessary for
	connection handling and management, e.g., the TLS parent		connection handling and management, e.g., the TLS parent
	connection protocol type via ALPN [RFC7301] or desired application		connection protocol type via ALPN [RFC7301] or desired application
	identity via SNI [RFC6066].		identity via SNI [RFC6066].
	o Configuration extensions: Add protocol features via extensions or		o Configuration extensions: Add protocol features via extensions or
	configuration options. TLS extensions are a primary example of		configuration options. TLS extensions are a primary example of
	this feature.		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 Source validation (cookie or puzzle based): Peer source validation		o Source validation (cookie or puzzle based): Peer source validation
	and DoS mitigation via explicit proof of origin (cookie) or work		and DoS mitigation via explicit proof of origin (cookie) or work
	mechanisms (puzzles).		mechanisms (puzzles).
	o Connection re-keying: In-band cryptographic handshake re-keying.
	o Length-hiding padding: Protocol-drive record padding aimed at		o Length-hiding padding: Protocol-drive record padding aimed at
	hiding plaintext message length and mitigating amplification		hiding plaintext message length and 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
	skipping to change at page 18, line 23 ¶		skipping to change at page 17, line 50 ¶
	4.6.2. Security 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 Session caching and management.
	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
	skipping to change at page 20, line 33 ¶		skipping to change at page 20, line 7 ¶
	Connections are instances of user-authenticated, mobile sessions		Connections are instances of user-authenticated, mobile sessions
	between two endpoints. Connections run within tunnels between hosts.		between two endpoints. Connections run within tunnels between hosts.
	A tunnel is a server-authenticated container that multiplexes		A tunnel is a server-authenticated container that multiplexes
	multiple connections between the same hosts. All connections in a		multiple connections between the same hosts. All connections in a
	tunnel share the same transport state machine and encryption. Each		tunnel share the same transport state machine and encryption. Each
	tunnel has a dedicated control connection used to configure and		tunnel has a dedicated control connection used to configure and
	manage the tunnel over time. Moreover, since tunnels are independent		manage the tunnel over time. Moreover, since tunnels are independent
	of the network address information, they may be reused as both ends		of the network address information, they may be reused as both ends
	of the tunnel move about the network. This does however imply that		of the tunnel move about the network. This does however imply that
	the connection establishment and packet encryption mechanisms are		connection establishment and packet encryption mechanisms are
	coupled.		coupled.
	Before a client connects to a remote service, it must first establish		Before a client connects to a remote service, it must first establish
	a tunnel to the host providing or offering the service. Tunnels are		a tunnel to the host providing or offering the service. Tunnels are
	established in 1-RTT using an ephemeral key obtained from the		established in 1-RTT using an ephemeral key obtained from the
	directory service. Tunnel initiators provide their own ephemeral key		directory service. Tunnel initiators provide their own ephemeral key
	and, optionally, a DoS puzzle solution such that the recipient		and, optionally, a DoS puzzle solution such that the recipient
	(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.
	skipping to change at page 21, line 46 ¶		skipping to change at page 21, line 20 ¶
	under the server's long-term public key. The server replies with a		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		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		by the client. Upon receipt, the client then generates its second
	initialization packet carrying: the ephemeral key C', cookie, and an		initialization packet carrying: the ephemeral key C', cookie, and an
	encryption of C', the server's domain name, and, optionally, some		encryption of C', the server's domain name, and, optionally, some
	message data. The server verifies the cookie and the encrypted		message data. The server verifies the cookie and the encrypted
	payload and, if valid, proceeds to send data in return. At this		payload and, if valid, proceeds to send data in return. At this
	point, the connection is established and the two parties can		point, the connection is established and the two parties can
	communicate.		communicate.
	The use of only public-key encryption and authentication, or		The use of public-key encryption and authentication, or "boxing", is
	"boxing", is done to simplify problems that come with symmetric key		done to simplify problems that come with symmetric key management and
	management and synchronization. For example, it allows the sender of		synchronization. For example, it allows the sender of a message to
	a message to be in complete control of each message's nonce. It does		be in complete control of each message's nonce. It does not require
	not require either end to share secret keying material. Furthermore,		either end to share secret keying material. Furthermore, it allows
	it allows connections (or sessions) to be associated with unique		connections (or sessions) to be associated with unique ephemeral
	ephemeral public keys as a mechanism for enabling forward secrecy		public keys as a mechanism for enabling forward secrecy given the
	given the risk of long-term private key compromise.		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.
	Servers use cookies for source validation. After receiving a		Servers use cookies for source validation. After receiving a
	skipping to change at page 23, line 12 ¶		skipping to change at page 22, line 30 ¶
	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. They were selected on the basis that they are either		implementation. They were selected on the basis that they are either
	(a) required for any secure transport protocol or (b) nearly		(a) required for any secure transport protocol or (b) nearly
	ubiquitous amongst common secure transport protocols. Optional		ubiquitous amongst common secure transport protocols.
	features by contrast may vary from implementation to implementation,
	and so an application cannot simply assume they are available.		Optional features by contrast may vary from implementation to
	Applications learn of and use optional features by querying for their		implementation, and so an application cannot simply assume they are
	presence and support. Optional features may not be implemented, or		available. Applications learn of and use optional features by
	may be disabled if their presence impacts transport services or if a		querying for their presence and support. Optional features may not
	necessary transport service is unavailable.		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 one required from an application in order to function.
	5.1. Mandatory Features		5.1. Mandatory Features
	o Segment or datagram encryption and authentication: Protect transit		Mandatory features must be supported regardless of transport and
	data with an authenticated encryption algorithm.		application services available.
			o Record or datagram confidentiality and integrity.
	o Forward-secure key establishment.		o Forward-secure key establishment.
	o Public-key (raw or certificate) based authentication.		o Public-key certificate based authentication.
	o Unilateral responder authentication.		o Unilateral responder authentication.
	o Pre-shared key support.		Note that most systems provide defailt trust stores used to
			authenticate peers based on certificates. In such systems,
			applications need not provide any trust information. Applications
			running on systems without such a feature must necessary depend on
			applications for this information so as to authenticate peers.
	5.2. Optional Features		5.2. Optional Features
	o Cryptographic algorithm negotiation (AN):		In this section we list optional features along with their necessary
			application dependencies, if any.
	* Transport dependency: None.		o Pre-shared key support (PSK):
			* Application dependency: Application provisioning and
			distribution of pre-shared keys.
			o Cryptographic algorithm negotiation (AN):
	* Application dependency: Application awareness of supported or		* Application dependency: Application awareness of supported or
	desired algorithms.		desired algorithms.
	o Application authentication delegation (AD):		o Application authentication delegation (AD):
	* 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):		o Mutual authentication (MA):
	* Transport dependency: None.		* Application dependency: Mutual authentication credentials
			required for application support.
	* Application dependency: Mutual authentication required for
	application support.
	o DoS mitigation (DM):		o DoS mitigation (DM):
	* Transport dependency: None.
	* Application dependency: None.		* Application dependency: None.
	o Connection mobility (CM):		o Connection mobility (CM):
	* Transport dependency: Connections are unreliable or can change
	due to unpredictable network events, e.g., NAT re-bindings.
	* Application dependency: None.		* Application dependency: None.
	o Source validation (SV):		o Source validation (SV):
	* Transport dependency: Packets may arrive as datagrams instead
	of streams from unauthenticated sources.
	* Application dependency: None.		* Application dependency: None.
	o Application-layer feature negotiation (AFN):		o Application-layer feature negotiation (AFN):
	* 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):		o Configuration extensions (CX):
	* Transport dependency: None.
	* Application dependency: Specification of application-specific		* Application dependency: Specification of application-specific
	extensions.		extensions.
	o Session caching and management (SC):		o Session caching and management (SC):
	* Transport dependency: None.
	* Application dependency: None.		* Application dependency: None.
	o Early data support (ED):		o Length-hiding padding (LHP):
	* Transport dependency: None.		* Application dependency: Knowledge of desired padding policies.
			o Early data support (ED):
	* Application dependency: Anti-replay protections or hints of		* Application dependency: Anti-replay protections or hints of
	data idempotency.		data idempotency.
	o Length-hiding padding (LHP):		o Record replay prevention (RP):
	* Transport dependency: None.		* Application dependency: None.
	* Application dependency: Knowledge of desired padding policies.		o Out-of-order receipt record (OO):
			* Application dependency: None.
	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 | A | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | ED |		| Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO |
	| | N | | | | | | | | | | |		| toc | S | N | D | A | M | M | V | F | | | P | | | |
	+----------+---+----+----+-----+----+----+-----+----+----+-----+----+		| ol | K | | | | | | | N | | | | | | |
	| TLS | S | S | S | S | U* | M | S | S | S | S | S |		+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
	| | | | | | | | | | | | |		| TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U |
	| DTLS | S | S | S | S | S | M | S | S | S | S | U |		| | | | | | | * | | | | | | | | |
	| | | | | | | | | | | | |		| | | | | | | | | | | | | | | |
	| IETF | S | S | S | S | S | M | S | S | S | S | S |		| DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M |
	| QUIC | | | | | | | | | | | |		| S | | | | | | | | | | | | | | |
	| | | | | | | | | | | | |		| | | | | | | | | | | | | | | |
	| IKEv2+ES | S | S | M | S | S | M | S | S | S | S | U |		| IET | S | S | S | S | S | S | M | S | S | S | S | S | M | M |
	| P | | | | | | | | | | | |		| F Q | | | | | | | | | | | | | | |
	| | | | | | | | | | | | |		| UIC | | | | | | | | | | | | | | |
	| SRTP+DTL | S | S | S | S | U | M | S | S | S | U | U |		| | | | | | | | | | | | | | | |
	| S | | | | | | | | | | | |		| IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M |
	| | | | | | | | | | | | |		| v2+ | | | | | | | | | | | | | | |
	| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | U |		| ESP | | | | | | | | | | | | | | |
	| | | | | | | | | | | | |		| | | | | | | | | | | | | | | |
	| WireGuar | U | S | M | S | U | M | U | U | U | S+ | U |		| SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M |
	| d | | | | | | | | | | | |		| P+D | | | | | | | | | | | | | | |
	| | | | | | | | | | | | |		| TLS | | | | | | | | | | | | | | |
	| MinimalT | U | U | M | S | M | M | U | U | U | S | U |		| | | | | | | | | | | | | | | |
	| | | | | | | | | | | | |		| tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U |
	| CurveCP | U | U | S | S | M | M | U | U | U | S | 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;		M=Mandatory S=Supported but not required U=Unsupported *=On TCP;
	MPTCP would provide this ability **=TCP provides SYN cookies		MPTCP would provide this ability **=TCP provides SYN cookies
	natively, but these are not cryptographically strong +=For transport		natively, but these are not cryptographically strong +=For transport
	packets only		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		following conventions in [I-D.ietf-taps-interface] and
	[I-D.ietf-taps-arch].		[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 The application can provide its		o Identities and Private Keys The application can provide its
	identities (certificates) and private keys, or mechanisms to		identities (certificates) and private keys, or mechanisms to
	access these, to the security protocol to use during handshakes.		access these, to the security 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. Protocols: TLS, DTLS,		key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS,
	QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP		QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP
			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].
			Protocols: TLS, DTLS, QUIC + TLS
	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. Protocols: TLS, DTLS, QUIC + TLS, MinimalT		session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT
	o Authentication Delegation The application provides access to a		o Authentication Delegation The application provides access to a
	separate module that will provide authentication, using EAP for		separate module that will provide authentication, using EAP for
	example. Protocols: IKEv2, SRTP		example. Protocols: IKEv2, SRTP
	o Pre-Shared Key Import Either the handshake protocol or the		o Pre-Shared Key Import Either the handshake protocol or the
	skipping to change at page 27, line 23 ¶		skipping to change at page 27, line 25 ¶
	o Source Address Validation The handshake protocol may delegate		o Source Address Validation The handshake protocol may delegate
	validation of the remote peer that has sent data to the transport		validation of the remote peer that has sent data to the transport
	protocol or application. This involves sending a cookie exchange		protocol or application. This involves sending a cookie exchange
	to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard		to avoid DoS attacks. 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, MinimalT, tcpcrypt, IKEv2
	o Key Update The handshake protocol may be instructed to update its		o Key Update The handshake protocol may be instructed to update its
	keying material, either by the application directly or by the		keying material, either by the application directly or by the
	record protocol sending a key expiration event. Protocols: TLS,		record protocol sending a key expiration event. Protocols: TLS,
	DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2		DTLS, QUIC, 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)
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 5 ¶
	* 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. Protocols: ESP ((Editor's note:
	One may consider TLS/DTLS to also have this interface))		One may consider TLS/DTLS to also have this interface))
	o Connection mobility The record protocol can be signaled that it is		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.		mobility, which may reset address and state validation and induce
			state changes such as use of a new Connection Identifier (CID).
	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
	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. Acknowledgments		9. Privacy Considerations
	The authors would like to thank Mirja Kuehlewind, Brian Trammell,		Analysis of how features improve or degrade privacy is intentionally
	Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and		omitted from this survey. All security protocols surveyed generally
	feedback on earlier versions of this draft.		improve privacy by reducing information leakage via encryption.
			However, varying amounts of metadata remain in the clear across each
			protocol. For example, client and server certificates are sent in
			cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
			[RFC8446]. A survey of privacy features, or lack thereof, for
			various security protocols could be addressed in a separate document.
	10. Normative References		10. Acknowledgments
			The authors would like to thank Bob Bradley, Theresa Enghardt,
			Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell
			for their input and feedback on earlier versions of this draft.
			11. Normative References
	[ALTS] "Application Layer Transport Security", n.d..		[ALTS] "Application Layer Transport Security", n.d..
	[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-15 (work in		(TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in
	progress), October 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-15 (work		and Secure Transport", draft-ietf-quic-transport-16 (work
	in progress), October 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-15 (work in progress), July 2018.		rtcweb-security-arch-16 (work in progress), October 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-02 (work in		Transport Services", draft-ietf-taps-arch-02 (work in
	progress), October 2018.		progress), October 2018.
	[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., and C. Wood, "An		Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
	Abstract Application Layer Interface to Transport		Abstract Application Layer Interface to Transport
	Services", draft-ietf-taps-interface-02 (work in		Services", draft-ietf-taps-interface-02 (work in
	progress), October 2018.		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-13 (work in		(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-14 (work in
	progress), September 2018.		progress), November 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		"Connection Identifiers for DTLS 1.2", draft-ietf-tls-
	Identifier", draft-ietf-tls-dtls-connection-id-01 (work in		dtls-connection-id-02 (work in progress), October 2018.
	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-28 (work in progress), July		1.3", draft-ietf-tls-dtls13-29 (work in progress), October
	2018.		2018.
	[I-D.ietf-tls-record-limit]		[I-D.ietf-tls-record-limit]
	Thomson, M., "Record Size Limit Extension for Transport		Thomson, M., "Record Size Limit Extension for Transport
	Layer Security (TLS)", draft-ietf-tls-record-limit-03		Layer Security (TLS)", draft-ietf-tls-record-limit-03
	(work in progress), May 2018.		(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),
	skipping to change at page 30, line 22 ¶		skipping to change at page 30, line 33 ¶
	Security", n.d..		Security", n.d..
	[Noise] "The Noise Protocol Framework", n.d..		[Noise] "The Noise Protocol Framework", n.d..
	[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		[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
	Headers for Low-Speed Serial Links", RFC 2508,		Headers for Low-Speed Serial Links", RFC 2508,
	DOI 10.17487/RFC2508, February 1999,		DOI 10.17487/RFC2508, February 1999, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2508>.		editor.org/info/rfc2508>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3261>.		editor.org/info/rfc3261>.
	[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and		[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
	P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with		P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
	High Delay, Packet Loss and Reordering", RFC 3545,		High Delay, Packet Loss and Reordering", RFC 3545,
	DOI 10.17487/RFC3545, July 2003,		DOI 10.17487/RFC3545, July 2003, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3545>.		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.		[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
	Stenberg, "UDP Encapsulation of IPsec ESP Packets",		Stenberg, "UDP Encapsulation of IPsec ESP Packets",
	RFC 3948, DOI 10.17487/RFC3948, January 2005,		RFC 3948, DOI 10.17487/RFC3948, January 2005,
	<https://www.rfc-editor.org/info/rfc3948>.		<https://www.rfc-editor.org/info/rfc3948>.
	[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,		Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
	January 2006, <https://www.rfc-editor.org/info/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-
	<https://www.rfc-editor.org/info/rfc4302>.		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>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,		Initiation Protocol (SIP)", RFC 4474,
	DOI 10.17487/RFC4474, August 2006,		DOI 10.17487/RFC4474, August 2006, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc4474>.		editor.org/info/rfc4474>.
	[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol		[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
	(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,		(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
	<https://www.rfc-editor.org/info/rfc4555>.		<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-
	<https://www.rfc-editor.org/info/rfc5246>.		editor.org/info/rfc5246>.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange		[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
	Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,		Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
	DOI 10.17487/RFC5723, January 2010,		DOI 10.17487/RFC5723, January 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5723>.		editor.org/info/rfc5723>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.		2010, <https://www.rfc-editor.org/info/rfc5763>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764,		Real-time Transport Protocol (SRTP)", RFC 5764,
	DOI 10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5764>.		editor.org/info/rfc5764>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5869>.		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)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,		Extensions: Extension Definitions", RFC 6066,
	DOI 10.17487/RFC6066, January 2011,		DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6066>.		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>.
	skipping to change at page 32, line 42 ¶		skipping to change at page 32, line 51 ¶
	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>.
	[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,		Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
	<https://www.rfc-editor.org/info/rfc7539>.		<https://www.rfc-editor.org/info/rfc7539>.
	[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-
	<https://www.rfc-editor.org/info/rfc8095>.		editor.org/info/rfc8095>.
	[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>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
	[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated		[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated
	Diffie-Hellman and Its Use in the IKE-Protocols", n.d..		Diffie-Hellman and Its Use in the IKE-Protocols", n.d..
	[WireGuard]		[WireGuard]
	"WireGuard -- Next Generation Kernel Network Tunnel",		"WireGuard -- Next Generation Kernel Network Tunnel",
	n.d..		n.d..
	Authors' Addresses		Authors' Addresses
	Tommy Pauly		Tommy Pauly
End of changes. 73 change blocks.
	165 lines changed or deleted		188 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/