draft-ietf-taps-transport-security-05.txt		draft-ietf-taps-transport-security-06.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: August 30, 2019 TU Berlin		Expires: September 12, 2019 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.
	February 26, 2019		March 11, 2019
	A Survey of Transport Security Protocols		A Survey of Transport Security Protocols
	draft-ietf-taps-transport-security-05		draft-ietf-taps-transport-security-06
	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 48 ¶		skipping to change at page 1, line 48 ¶
	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 August 30, 2019.		This Internet-Draft will expire on September 12, 2019.
	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 19, line 25 ¶		skipping to change at page 19, line 25 ¶
	derivation.		derivation.
	o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption.		o ChaCha20+Poly1305 [RFC7539] 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.
	WireGuard is designed to be entirely stateless, modulo the CryptoKey		If a WireGuard receiver is under heavy load and cannot process a
	routing table, which has size linear with the number of trusted		packet, e.g., cannot spare CPU cycles for expensive public key
	peers. If a WireGuard receiver is under heavy load and cannot		cryptographic operations, it can reply with a cookie similar to DTLS
	process a packet, e.g., cannot spare CPU cycles for point		and IKEv2. This cookie only proves IP address ownership. Any rate
	multiplication, it can reply with a cookie similar to DTLS and IKEv2.		limiting scheme can be applied to packets coming from non-spoofed
	This cookie only proves IP address ownership. Any rate limiting		addresses.
	scheme can be applied to packets coming from non-spoofed addresses.
	4.7.2. Security Features		4.7.2. Security Features
	o Forward-secure session key establishment.		o Forward-secure session key establishment.
	o Peer authentication (public-key and PSK).		o Peer authentication (public-key and PSK).
	o Mutual authentication.		o Mutual authentication.
	o Record replay prevention (Stateful, timestamp-based).		o Record replay prevention (Stateful, timestamp-based).
			o Connection mobility.
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	4.7.3. Protocol Dependencies		4.7.3. Protocol Dependencies
	o Datagram transport.		o Datagram transport.
	o Out-of-band key distribution and management.		o Out-of-band key distribution and management.
	4.8. CurveCP		4.8. CurveCP
	skipping to change at page 23, line 41 ¶		skipping to change at page 23, line 41 ¶
	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
	rekeying using TLS.		rekeying 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 signs the payload using an		i.e., IP packets or Ethernet frames, and authenticates the payload
	HMAC function. The default cipher is BlowFish [BlowFish] and the		using HMAC. Applications can select an arbitrary encryption
	default message digest algorithm is SHA1, but an application can		algorithm (cipher) and key size, as well hash function for HMAC. The
	select an arbitrary cipher, key size, and message digest algorithm		default cipher and hash functions are AES-GCM and SHA1, respectively.
	for the HMAC. OpenVPN peers support cipher negotiation (NCP) since		Recent versions of the protocol support cipher negotiation.
	version 2.4, in which case they will upgrade the cipher to AES-
	256-GCM by default.
	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
	TLS handshake and key exchange. It assigns sequence numbers to		TLS handshake and key exchange. It assigns sequence numbers to
	packets, acknowledges packets it receives, and retransmits packets it		packets, acknowledges packets it receives, and retransmits packets it
	deems lost. Similar to DTLS, this reliability layer is not used for		deems lost. Similar to DTLS, this reliability layer is not used for
	data packets, which prevents the problem of two reliability		data packets, which prevents the problem of two reliability
	mechanisms being encapsulated within each other. When running over		mechanisms being encapsulated within each other. When running over
	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.
	skipping to change at page 31, line 50 ¶		skipping to change at page 31, line 50 ¶
	The authors would like to thank Bob Bradley, Theresa Enghardt,		The authors would like to thank Bob Bradley, Theresa Enghardt,
	Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell		Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell
	for their input and feedback on earlier versions of this draft.		for their input and feedback on earlier versions of this draft.
	11. Normative References		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..
	[BlowFish]
	"The Blowfish Encryption Algorithm", 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 TLS to Secure QUIC",		Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
	draft-ietf-quic-tls-18 (work in progress), January 2019.		draft-ietf-quic-tls-18 (work in progress), January 2019.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	skipping to change at page 32, line 48 ¶		skipping to change at page 32, line 45 ¶
	Q., and E. Smith, "Cryptographic protection of TCP Streams		Q., and E. Smith, "Cryptographic protection of TCP Streams
	(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in		(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in
	progress), December 2018.		progress), December 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., and T. Fossati, "Connection
	"Connection Identifiers for DTLS 1.2", draft-ietf-tls-		Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
	dtls-connection-id-02 (work in progress), October 2018.		id-04 (work in progress), March 2019.
	[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-30 (work in progress),		1.3", draft-ietf-tls-dtls13-30 (work in progress),
	November 2018.		November 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
End of changes. 9 change blocks.
	24 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/