draft-ietf-taps-transport-security-08.txt		draft-ietf-taps-transport-security-09.txt
	Network Working Group C. Wood, Ed.		Network Working Group C. Wood, Ed.
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Informational T. Enghardt		Intended status: Informational T. Enghardt
	Expires: February 8, 2020 TU Berlin		Expires: March 31, 2020 TU Berlin
	T. Pauly		T. Pauly
	Apple Inc.		Apple Inc.
	C. Perkins		C. Perkins
	University of Glasgow		University of Glasgow
	K. Rose		K. Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	August 07, 2019		September 28, 2019
	A Survey of Transport Security Protocols		A Survey of Transport Security Protocols
	draft-ietf-taps-transport-security-08		draft-ietf-taps-transport-security-09
	Abstract		Abstract
	This document provides a survey of commonly used or notable network		This document provides a survey of commonly used or notable network
	security protocols, with a focus on how they interact and integrate		security protocols, with a focus on how they interact and integrate
	with applications and transport protocols. Its goal is to supplement		with applications and transport protocols. Its goal is to supplement
	efforts to define and catalog transport services by describing the		efforts to define and catalog transport services by describing the
	interfaces required to add security protocols. This survey is not		interfaces required to add security protocols. This survey is not
	limited to protocols developed within the scope or context of the		limited to protocols developed within the scope or context of the
	IETF, and those included represent a superset of features a Transport		IETF, and those included represent a superset of features a Transport
	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 February 8, 2020.		This Internet-Draft will expire on March 31, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 42 ¶
	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
	TLS (Transport Layer Security) [RFC5246] is a common protocol used to		TLS (Transport Layer Security) [RFC8446] is a common protocol used to
	establish a secure session between two endpoints. Communication over		establish a secure session between two endpoints. Communication over
	this session "prevents eavesdropping, tampering, and message		this session "prevents eavesdropping, tampering, and message
	forgery." TLS consists of a tightly coupled handshake and record		forgery." TLS consists of a tightly coupled handshake and record
	protocol. The handshake protocol is used to authenticate peers,		protocol. The handshake protocol is used to authenticate peers,
	negotiate protocol options, such as cryptographic algorithms, and		negotiate protocol options, such as cryptographic algorithms, and
	derive session-specific keying material. The record protocol is used		derive session-specific keying material. The record protocol is used
	to marshal (possibly encrypted) data from one peer to the other.		to marshal (possibly encrypted) data from one peer to the other.
	This data may contain handshake messages or raw application data.		This data may contain handshake messages or raw application data.
	4.1.1. Protocol Description		4.1.1. Protocol Description
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 45 ¶
	4.1.3. Protocol Dependencies		4.1.3. Protocol Dependencies
	o In-order, reliable bytestream transport.		o In-order, reliable bytestream 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,
	but differs in that it is designed to run over unrelaible datagram		but differs in that it is designed to run over unreliable datagram
	protocols like UDP instead of TCP. DTLS modifies the protocol to		protocols like UDP instead of TCP. DTLS modifies the protocol to
	make sure it can still provide the same security guarantees as TLS		make sure it can still provide the same security guarantees as TLS
	even without reliability from the transport. DTLS was designed to be		even without reliability from the transport. DTLS was designed to be
	as similar to TLS as possible, so this document assumes that all		as similar to TLS as possible, so this document assumes that all
	properties from TLS are carried over except where specified.		properties from TLS are carried over except where specified.
	4.2.1. Protocol Description		4.2.1. Protocol Description
	DTLS is modified from TLS to operate with the possibility of packet		DTLS is modified from TLS to operate with the possibility of packet
	loss, reordering, and duplication that may occur when operating over		loss, reordering, and duplication that may occur when operating over
	skipping to change at page 10, line 31 ¶		skipping to change at page 10, line 31 ¶
	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, or a		DTLS relies on unique UDP 4-tuples to identify connections, or a
	similar mechanism in other datagram transports. Since all		similar mechanism in other datagram transports. Since all
	application-layer data is encrypted, demultiplexing over the same		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. Security 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.
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 17 ¶
	as the Initial and Handshake packets.		as the Initial and Handshake packets.
	4.3.2. Security 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 assumes an unreliable transport, e.g., UDP.
	o QUIC transport relies on TLS 1.3 for key exchange, peer		o QUIC transport relies on TLS 1.3 for key exchange, peer
	authentication, and shared secret derivation.		authentication, and shared secret derivation.
	o For the handshake: Reliable, in-order transport. QUIC provides		o For the handshake: Reliable, in-order transport. QUIC provides
	its own reliability.		its own reliability.
	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
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function		Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
	algorithm. Each peer may support multiple proposals, and the most		algorithm. Each peer may support multiple proposals, and the most
	preferred mutually supported proposal is chosen during the handshake.		preferred mutually supported proposal is chosen during the handshake.
	The authentication phase of IKEv2 may use Shared Secrets,		The authentication phase of IKEv2 may use Shared Secrets,
	Certificates, Digital Signatures, or an EAP (Extensible		Certificates, Digital Signatures, or an EAP (Extensible
	Authentication Protocol) method. At a minimum, IKEv2 takes two round		Authentication Protocol) method. At a minimum, IKEv2 takes two round
	trips to set up both an IKE SA and a Child SA. If EAP is used, this		trips to set up both an IKE SA and a Child SA. If EAP is used, this
	exchange may be expanded.		exchange may be expanded.
	Any SA used by IKEv2 can be rekeyed before expiration, which is		Any SA used by IKEv2 can be re-keyed before expiration, which is
	usually based either on time or number of bytes encrypted.		usually based either on time or number of bytes encrypted.
	There is an extension to IKEv2 that allows session resumption		There is an extension to IKEv2 that allows session resumption
	[RFC5723].		[RFC5723].
	MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a		MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
	set of Security Associations to migrate over different outer IP		set of Security Associations to migrate over different outer IP
	addresses and interfaces [RFC4555].		addresses and interfaces [RFC4555].
	When UDP is not available or well-supported on a network, IKEv2 may		When UDP is not available or well-supported on a network, IKEv2 may
	skipping to change at page 16, line 15 ¶		skipping to change at page 16, line 15 ¶
	SRTP offers replay detection by keeping a replay list of already seen		SRTP offers replay detection by keeping a replay list of already seen
	and processed packet indices. If a packet arrives with an index that		and processed packet indices. If a packet arrives with an index that
	matches one in the replay list, it is silently discarded.		matches one in the replay list, it is silently discarded.
	DTLS [RFC5764] is commonly used to perform mutual authentication and		DTLS [RFC5764] is commonly used to perform mutual authentication and
	key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual		key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual
	certificate-based authentication on the media path, and to generate		certificate-based authentication on the media path, and to generate
	the SRTP master key. Peer certificates can be issued and signed by a		the SRTP master key. Peer certificates can be issued and signed by a
	certificate authority. Alternatively, certificates used in the DTLS		certificate authority. Alternatively, certificates used in the DTLS
	exchange can be self-signed. If they are self-signed, certificate		exchange can be self-signed. If they are self-signed, certificate
	fingerprints are included in the signalling exchange (e.g., in SIP or		fingerprints are included in the signaling exchange (e.g., in SIP or
	WebRTC), and used to bind the DTLS key exchange in the media plane to		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,		signaling channel protects against active attacks on the media,
	provided the signalling can be trusted. Signalling needs to be		provided the signaling can be trusted. Signaling 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 [RFC8224] 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. Security Features		4.5.2. Security Features
	o Forward-secure session key establishment.		o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Mutual authentication.		o Mutual authentication.
	skipping to change at page 16, line 50 ¶		skipping to change at page 16, line 50 ¶
	o Out-of-order record receipt.		o Out-of-order record receipt.
	4.5.3. Protocol Dependencies		4.5.3. Protocol Dependencies
	o Secure RTP can run over UDP or TCP.		o Secure RTP can run over UDP or TCP.
	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 [RFC8224], 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
	ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It		ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
	uses standard SRTP to protect RTP data packets and RTCP packets, but		uses standard SRTP to protect RTP data packets and RTCP packets, but
	provides alternative key agreement and identity management protocols.		provides alternative key agreement and identity management protocols.
	Key agreement is performed using a Diffie-Hellman key exchange that		Key agreement is performed using a Diffie-Hellman key exchange that
	runs on the media path. This generates a shared secret that is then		runs on the media path. This generates a shared secret that is then
	skipping to change at page 17, line 28 ¶		skipping to change at page 17, line 28 ¶
	requires endpoints to display a short authentication string that the		requires endpoints to display a short authentication string that the
	users must read and verbally compare to validate the hashes and		users must read and verbally compare to validate the hashes and
	ensure security. Endpoints cache some key material after the first		ensure security. Endpoints cache some key material after the first
	call to use in subsequent calls; this is mixed in with the Diffie-		call to use in subsequent calls; this is mixed in with the Diffie-
	Hellman shared secret, so the short authentication string need only		Hellman shared secret, so the short authentication string need only
	be checked once for a given user. This gives key continuity		be checked once for a given user. This gives key continuity
	properties analogous to the secure shell (ssh) [RFC4253].		properties analogous to the secure shell (ssh) [RFC4253].
	4.6. tcpcrypt		4.6. tcpcrypt
	Tcpcrypt is a lightweight extension to the TCP protocol for		Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
	opportunistic encryption. Applications may use tcpcrypt's unique		opportunistic encryption. Applications may use tcpcrypt's unique
	session ID for further application-level authentication. Absent this		session ID for further application-level authentication. Absent this
	authentication, tcpcrypt is vulnerable to active attacks.		authentication, tcpcrypt is vulnerable to active attacks.
	4.6.1. Protocol Description		4.6.1. Protocol Description
	Tcpcrypt extends TCP to enable opportunistic encryption between the		Tcpcrypt extends TCP to enable opportunistic encryption between the
	two ends of a TCP connection [RFC8548]. It is a family of TCP		two ends of a TCP connection [RFC8548]. It is a family of TCP
	encryption protocols (TEP), distinguished by key exchange algorithm.		encryption protocols (TEP), distinguished by key exchange algorithm.
	The use of a TEP is negotiated with a TCP option during the initial		The use of a TEP is negotiated with a TCP option during the initial
	skipping to change at page 19, line 25 ¶		skipping to change at page 19, line 25 ¶
	cryptographic computations.		cryptographic computations.
	WireGuard builds on Noise [Noise] for 1-RTT key exchange with		WireGuard builds on Noise [Noise] for 1-RTT key exchange with
	identity hiding. The handshake hides peer identities as per the		identity hiding. The handshake hides peer identities as per the
	SIGMA construction [SIGMA]. As a consequence of using Noise,		SIGMA construction [SIGMA]. As a consequence of using Noise,
	WireGuard comes with a fixed set of cryptographic algorithms:		WireGuard comes with a fixed set of cryptographic algorithms:
	o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key		o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key
	derivation.		derivation.
	o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption.		o ChaCha20+Poly1305 [RFC8439] for packet authenticated encryption.
	o BLAKE2s [BLAKE2] for hashing.		o BLAKE2s [BLAKE2] for hashing.
	There is no cryptographic agility. If weaknesses are found in any of		There is no cryptographic agility. If weaknesses are found in any of
	these algorithms, new message types using new algorithms must be		these algorithms, new message types using new algorithms must be
	introduced.		introduced.
	If a WireGuard receiver is under heavy load and cannot process a		If a WireGuard receiver is under heavy load and cannot process a
	packet, e.g., cannot spare CPU cycles for expensive public key		packet, e.g., cannot spare CPU cycles for expensive public key
	cryptographic operations, it can reply with a cookie similar to DTLS		cryptographic operations, it can reply with a cookie similar to DTLS
	skipping to change at page 23, line 49 ¶		skipping to change at page 23, line 49 ¶
	OpenVPN facilitates authentication using either a pre-shared static		OpenVPN facilitates authentication using either a pre-shared static
	key or using X.509 certificates and TLS. In pre-shared key mode,		key or using X.509 certificates and TLS. In pre-shared key mode,
	OpenVPN derives keys for encryption and authentication directly from		OpenVPN derives keys for encryption and authentication directly from
	one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a		one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a
	TLS handshake, in which both peers must present a certificate for		TLS handshake, in which both peers must present a certificate for
	authentication. After the handshake, both sides contribute random		authentication. After the handshake, both sides contribute random
	source material to derive keys for encryption and authentication		source material to derive keys for encryption and authentication
	using the TLS pseudo random function (PRF). OpenVPN provides the		using the TLS pseudo random function (PRF). OpenVPN provides the
	possibility to authenticate and encrypt the TLS handshake itself		possibility to authenticate and encrypt the TLS handshake itself
	using a pre-shared key or passphrase. Furthermore, it supports		using a pre-shared key or passphrase. Furthermore, it supports re-
	rekeying using TLS.		keying using TLS.
	After authentication and key exchange, OpenVPN encrypts payload data,		After authentication and key exchange, OpenVPN encrypts payload data,
	i.e., IP packets or Ethernet frames, and authenticates the payload		i.e., IP packets or Ethernet frames, and authenticates the payload
	using HMAC. Applications can select an arbitrary encryption		using HMAC. Applications can select an arbitrary encryption
	algorithm (cipher) and key size, as well hash function for HMAC. The		algorithm (cipher) and key size, as well hash function for HMAC. The
	default cipher and hash functions are AES-GCM and SHA1, respectively.		default cipher and hash functions are AES-GCM and SHA1, respectively.
	Recent versions of the protocol support cipher negotiation.		Recent versions of the protocol support cipher negotiation.
	OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN		OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN
	provides a simple reliability layer for control packets such as the		provides a simple reliability layer for control packets such as the
	skipping to change at page 24, line 29 ¶		skipping to change at page 24, line 29 ¶
	TCP, OpenVPN includes the packet length in the header, which allows		TCP, OpenVPN includes the packet length in the header, which allows
	the peer to deframe the TCP stream into messages.		the peer to deframe the TCP stream into messages.
	For replay protection, OpenVPN assigns an identifier to each outgoing		For replay protection, OpenVPN assigns an identifier to each outgoing
	packet, which is unique for the packet and the currently used key.		packet, which is unique for the packet and the currently used key.
	In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN		In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN
	combines a timestamp with an incrementing sequence number into a		combines a timestamp with an incrementing sequence number into a
	64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits		64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits
	the timestamp, so identifiers are only 32-bit. This is sufficient		the timestamp, so identifiers are only 32-bit. This is sufficient
	since OpenVPN can guarantee the uniqueness of this identifier for		since OpenVPN can guarantee the uniqueness of this identifier for
	each key, as it can trigger rekeying if needed.		each key, as it can trigger re-keying if needed.
	OpenVPN supports connection mobility by allowing a peer to change its		OpenVPN supports connection mobility by allowing a peer to change its
	IP address during an ongoing session. When configured accordingly, a		IP address during an ongoing session. When configured accordingly, a
	host will accept authenticated packets for a session from any IP		host will accept authenticated packets for a session from any IP
	address.		address.
	4.10.2. Protocol Features		4.10.2. Protocol Features
	o Peer authentication using certificates or pre-shared key.		o Peer authentication using certificates or pre-shared key.
	skipping to change at page 29, line 52 ¶		skipping to change at page 29, line 52 ¶
	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
	application directly can supply pre-shared keys for the record		application directly can supply pre-shared keys for the record
	protocol use for encryption/decryption and authentication. If the		protocol use for encryption/decryption and authentication. If the
	application can supply keys directly, this is considered explicit		application can supply keys directly, this is considered explicit
	import; if the handshake protocol traditionally provides the keys		import; if the handshake protocol traditionally provides the keys
	directly, it is considered direct import; if the keys can only be		directly, it is considered direct import; if the keys can only be
	shared by the handshake, they are considered non-importable.		shared by the handshake, they are considered non-importable.
	* Explict import: QUIC, ESP		* Explicit 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 During a handshake, the security protocol will		o Identity Validation During a handshake, the security protocol will
	conduct identity validation of the peer. This can call into the		conduct identity validation of the peer. This can call into the
	application to offload validation. Protocols: All (TLS, DTLS,		application to offload validation. Protocols: All (TLS, DTLS,
	QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))		QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
	skipping to change at page 31, line 41 ¶		skipping to change at page 31, line 41 ¶
	improve privacy by reducing information leakage via encryption.		improve privacy by reducing information leakage via encryption.
	However, varying amounts of metadata remain in the clear across each		However, varying amounts of metadata remain in the clear across each
	protocol. For example, client and server certificates are sent in		protocol. For example, client and server certificates are sent in
	cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3		cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
	[RFC8446]. A survey of privacy features, or lack thereof, for		[RFC8446]. A survey of privacy features, or lack thereof, for
	various security protocols could be addressed in a separate document.		various security protocols could be addressed in a separate document.
	10. Acknowledgments		10. Acknowledgments
	The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja		The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
	Kuehlewind, Yannick Sierra, and Brian Trammell for their input and		Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
	feedback on earlier versions of this draft.		their input and feedback on this draft.
	11. Informative References		11. Informative References
	[ALTS] "Application Layer Transport Security", n.d..		[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,
			B., and J. Boeuf, "Application Layer Transport Security",
			<https://cloud.google.com/security/encryption-in-transit/
			application-layer-transport-security/>.
	[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..		[BLAKE2] Aumasson, J., Neves, S., Wilcox-O'Hearn, Z., and C.
			Winnerlein, "BLAKE2 -- simpler, smaller, fast as MD5",
			<https://blake2.net/blake2.pdf>.
	[Curve25519]		[Curve25519]
	"Curve25519 - new Diffie-Hellman speed records", n.d..		Bernstein, D., "Curve25519 - new Diffie-Hellman speed
			records", <https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
	[CurveCP] "CurveCP -- Usable security for the Internet", n.d..		[CurveCP] Bernstein, D., "CurveCP -- Usable security for the
			Internet", <http://curvecp.org>.
	[I-D.ietf-quic-tls]		[I-D.ietf-quic-tls]
	Thomson, M. and S. Turner, "Using TLS to Secure QUIC",		Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
	draft-ietf-quic-tls-22 (work in progress), July 2019.		draft-ietf-quic-tls-23 (work in progress), September 2019.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-22 (work		and Secure Transport", draft-ietf-quic-transport-23 (work
	in progress), July 2019.		in progress), September 2019.
	[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-20 (work in progress), July 2019.		rtcweb-security-arch-20 (work in progress), July 2019.
	[I-D.ietf-taps-arch]		[I-D.ietf-taps-arch]
	Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,		Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
	Perkins, C., Tiesel, P., and C. Wood, "An Architecture for		Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
	Transport Services", draft-ietf-taps-arch-04 (work in		Transport Services", draft-ietf-taps-arch-04 (work in
	progress), July 2019.		progress), July 2019.
	skipping to change at page 32, line 43 ¶		skipping to change at page 33, line 5 ¶
	[I-D.ietf-taps-minset]		[I-D.ietf-taps-minset]
	Welzl, M. and S. Gjessing, "A Minimal Set of Transport		Welzl, M. and S. Gjessing, "A Minimal Set of Transport
	Services for End Systems", draft-ietf-taps-minset-11 (work		Services for End Systems", draft-ietf-taps-minset-11 (work
	in progress), September 2018.		in progress), September 2018.
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., and T. Fossati, "Connection		Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
	Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-		Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
	id-06 (work in progress), July 2019.		id-06 (work in progress), July 2019.
			[I-D.ietf-tls-dtls13]
			Rescorla, E., Tschofenig, H., and N. Modadugu, "The
			Datagram Transport Layer Security (DTLS) Protocol Version
			1.3", draft-ietf-tls-dtls13-32 (work in progress), July
			2019.
	[MinimalT]		[MinimalT]
	"MinimaLT -- Minimal-latency Networking Through Better		Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and
	Security", n.d..		T. Lange, "MinimaLT -- Minimal-latency Networking Through
			Better Security",
			<http://dl.acm.org/citation.cfm?id=2516737>.
	[Noise] "The Noise Protocol Framework", n.d..		[Noise] Perrin, T., "The Noise Protocol Framework",
			<http://noiseprotocol.org/noise.pdf>.
	[OpenVPN] "OpenVPN cryptographic layer", n.d..		[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/
			community-resources/openvpn-cryptographic-layer/>.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, DOI 10.17487/RFC2385, August		Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
	1998, <https://www.rfc-editor.org/info/rfc2385>.		1998, <https://www.rfc-editor.org/info/rfc2385>.
	[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP		[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-editor.org/info/rfc2508>.		<https://www.rfc-editor.org/info/rfc2508>.
	skipping to change at page 33, line 48 ¶		skipping to change at page 34, line 17 ¶
	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-editor.org/info/rfc4302>.		<https://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,
	DOI 10.17487/RFC4474, August 2006,
	<https://www.rfc-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-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange		[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
	skipping to change at page 35, line 21 ¶		skipping to change at page 35, line 35 ¶
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
	<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-editor.org/info/rfc8095>.		<https://www.rfc-editor.org/info/rfc8095>.
			[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
			"Authenticated Identity Management in the Session
			Initiation Protocol (SIP)", RFC 8224,
			DOI 10.17487/RFC8224, February 2018,
			<https://www.rfc-editor.org/info/rfc8224>.
	[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation		[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,		of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
	August 2017, <https://www.rfc-editor.org/info/rfc8229>.		August 2017, <https://www.rfc-editor.org/info/rfc8229>.
			[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
			Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
			<https://www.rfc-editor.org/info/rfc8439>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",		[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
	RFC 8449, DOI 10.17487/RFC8449, August 2018,		RFC 8449, DOI 10.17487/RFC8449, August 2018,
	<https://www.rfc-editor.org/info/rfc8449>.		<https://www.rfc-editor.org/info/rfc8449>.
	[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.		[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
	Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,		Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
	DOI 10.17487/RFC8547, May 2019,		DOI 10.17487/RFC8547, May 2019,
	<https://www.rfc-editor.org/info/rfc8547>.		<https://www.rfc-editor.org/info/rfc8547>.
	[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
	Q., and E. Smith, "Cryptographic Protection of TCP Streams		Q., and E. Smith, "Cryptographic Protection of TCP Streams
	(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,		(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
	<https://www.rfc-editor.org/info/rfc8548>.		<https://www.rfc-editor.org/info/rfc8548>.
	[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated		[SIGMA] Krawczyk, H., "SIGMA -- The 'SIGn-and-MAc' Approach to
	Diffie-Hellman and Its Use in the IKE-Protocols", n.d..		Authenticated Diffie-Hellman and Its Use in the IKE-
			Protocols", <http://www.iacr.org/cryptodb/archive/2003/
			CRYPTO/1495/1495.pdf>.
	[WireGuard]		[WireGuard]
	"WireGuard -- Next Generation Kernel Network Tunnel",		Donenfeld, J., "WireGuard -- Next Generation Kernel
	n.d..		Network Tunnel",
			<https://www.wireguard.com/papers/wireguard.pdf>.
	Authors' Addresses		Authors' Addresses
	Christopher A. Wood (editor)		Christopher A. Wood (editor)
	Apple Inc.		Apple Inc.
	One Apple Park Way		One Apple Park Way
	Cupertino, California 95014		Cupertino, California 95014
	United States of America		United States of America
	Email: cawood@apple.com		Email: cawood@apple.com
End of changes. 35 change blocks.
	47 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/