rfc8922xml2.original.xml		rfc8922.xml
			<?xml version="1.0" encoding="UTF-8"?>
			<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
			-ietf-taps-transport-security-12" number="8922" obsoletes="" updates="" submissi
			onType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" s
			ortRefs="true" symRefs="true" version="3">
			<front>
			<title abbrev="Transport Security Survey">A Survey of the Interaction
			between Security Protocols and Transport Services</title>
			<seriesInfo name="RFC" value="8922"/>
			<author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
			<organization>TU Berlin</organization>
			<address>
			<postal>
			<street>Marchstr. 23</street>
			<city>Berlin</city>
			<code>10587</code>
			<country>Germany</country>
			</postal>
			<email>ietf@tenghardt.net</email>
			</address>
			</author>
			<author initials="T." surname="Pauly" fullname="Tommy Pauly">
			<organization>Apple Inc.</organization>
			<address>
			<postal>
			<street>One Apple Park Way</street>
			<city>Cupertino</city><region>California</region><code>95014</code>
			<country>United States of America</country>
			</postal>
			<email>tpauly@apple.com</email>
			</address>
			</author>
			<author initials="C." surname="Perkins" fullname="Colin Perkins">
			<organization>University of Glasgow</organization>
			<address>
			<postal>
			<street>School of Computing Science</street>
			<city>Glasgow</city><code>G12 8QQ</code>
			<country>United Kingdom</country>
			</postal>
			<email>csp@csperkins.org</email>
			</address>
			</author>
			<author initials="K." surname="Rose" fullname="Kyle Rose">
			<organization>Akamai Technologies, Inc.</organization>
			<address>
			<postal>
			<street>150 Broadway</street>
			<city>Cambridge</city><region>MA</region><code>02144</code>
			<country>United States of America</country>
			</postal>
			<email>krose@krose.org</email>
			</address>
			</author>
			<author initials="C." surname="Wood" fullname="Christopher A. Wood">
			<organization>Cloudflare</organization>
			<address>
			<postal>
			<street>101 Townsend St</street>
			<city>San Francisco</city>
			<country>United States of America</country>
			</postal>
			<email>caw@heapingbits.net</email>
			</address>
			</author>
			<date year="2020" month="October"/>
			<keyword>Transport Protocols</keyword>
			<keyword>Transport Security</keyword>
			<abstract>
			<t>This document provides a survey of commonly used or notable network
			security protocols, with a focus on how they interact and integrate with
			applications and transport protocols. Its goal is to supplement efforts
			to define and catalog Transport Services by describing the interfaces
			required to add security protocols. This survey is not limited to
			protocols developed within the scope or context of the IETF, and those
			included represent a superset of features a Transport Services system
			may need to support.</t>
			</abstract>
			</front>
			<middle>
			<section anchor="introduction" numbered="true" toc="default">
			<name>Introduction</name>
			<t>Services and features provided by transport protocols have been
			cataloged in <xref target="RFC8095" format="default"/>. This document
			supplements that work by surveying commonly used and notable network
			security protocols, and identifying the interfaces between these
			protocols and both transport protocols and applications. It examines
			Transport Layer Security (TLS), Datagram Transport Layer Security
			(DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Protocol
			Security (IPsec), Secure Real-time Transport Protocol (SRTP) with DTLS,
			WireGuard, CurveCP, and MinimaLT. For each protocol, this document
			provides a brief description. Then, it describes the interfaces between
			these protocols and transports in <xref target="transport-interface"
			format="default"/> and the interfaces between these protocols and
			applications in <xref target="application-interface"
			format="default"/>.</t>
			<t>A Transport Services system exposes an interface for applications to
			access various (secure) transport protocol features. The security
			protocols included in this survey represent a superset of functionality
			and features a Transport Services system may need to support both
			internally and externally (via an API) for applications <xref
			target="I-D.ietf-taps-arch" format="default"/>. Ubiquitous IETF
			protocols such as (D)TLS, as well as non-standard protocols such as
			gQUIC, are included despite overlapping features. As such, this survey
			is not limited to protocols developed within the scope or context of the
			IETF. Outside of this candidate set, protocols that do not offer new
			features are omitted. For example, newer protocols such as WireGuard
			make unique design choices that have implications for and limitations on
			application usage. In contrast, protocols such as secure shell (SSH)
			<xref target="RFC4253" format="default"/>, GRE <xref target="RFC2890"
			format="default"/>, the Layer 2 Tunneling Protocol (L2TP) <xref
			target="RFC5641" format="default"/>, and Application Layer Transport
			Security (ALTS) <xref target="ALTS"
			format="default"/> are omitted since they do not provide interfaces
			deemed unique.</t>
			<t>Authentication-only protocols such as the TCP Authentication Option
			(TCP-AO) <xref target="RFC5925" format="default"/> and the IPsec
			Authentication Header (AH) <xref target="RFC4302" format="default"/> are
			excluded from this survey. TCP-AO adds authentication to long-lived TCP
			connections, e.g., replay protection with per-packet Message
			Authentication Codes. (TCP-AO obsoletes TCP MD5 "signature" options
			specified in <xref target="RFC2385" format="default"/>.) One primary use
			case of TCP-AO is for protecting BGP connections. Similarly, AH adds
			per-datagram authentication and integrity, along with replay
			protection. Despite these improvements, neither protocol sees general
			use and both lack critical properties important for emergent transport
			security protocols, such as confidentiality and privacy
			protections. Such protocols are thus omitted from this survey.</t>
			<t>This document only surveys point-to-point protocols; multicast protocol
			s are out of scope.</t>
			<section anchor="goals" numbered="true" toc="default">
			<name>Goals</name>
			<t>This survey is intended to help identify the most common interface
			surfaces between security protocols and transport protocols, and
			between security protocols and applications.</t>
			<t>One of the goals of the Transport Services effort is to define a
			common interface for using transport protocols that allows software
			using transport protocols to easily adopt new protocols that provide
			similar feature sets. The survey of the dependencies security
			protocols have upon transport protocols can guide implementations in
			determining which transport protocols are appropriate to be able to
			use beneath a given security protocol. For example, a security
			protocol that expects to run over a reliable stream of bytes, like
			TLS, restricts the set of transport protocols that can be used to
			those that offer a reliable stream of bytes.</t>
			<t>Defining the common interfaces that security protocols provide to
			applications also allows interfaces to be designed in a way that
			common functionality can use the same APIs. For example, many security
			protocols that provide authentication let the application be involved
			in peer identity validation. Any interface to use a secure transport
			protocol stack thus needs to allow applications to perform this action
			during connection establishment.</t>
			</section>
			<section anchor="non-goals" numbered="true" toc="default">
			<name>Non-goals</name>
			<t>While this survey provides similar analysis to that which was perform
			ed for transport protocols in <xref target="RFC8095" format="default"/>,
			it is important to distinguish that the use of security protocols requires more
			consideration.</t>
			<t>It is not a goal to allow software implementations to automatically
			switch between different security protocols, even where their
			interfaces to transport and applications are equivalent. Even between
			versions, security protocols have subtly different guarantees and
			vulnerabilities. Thus, any implementation needs to only use the set of
			protocols and algorithms that are requested by applications or by a
			system policy.</t>
			<t>Different security protocols also can use incompatible notions of
			peer identity and authentication, and cryptographic options. It is not
			a goal to identify a common set of representations for these
			concepts.</t>
			<t>The protocols surveyed in this document represent a superset of
			functionality and features a Transport Services system may need to
			support. It does not list all transport protocols that a Transport
			Services system may need to implement, nor does it mandate that a
			Transport Service system implement any particular protocol.</t>
			<t>A Transport Services system may implement any secure transport
			protocol that provides the described features. In doing so, it may
			need to expose an interface to the application to configure these
			features.</t>
			</section>
			</section>
			<section anchor="terminology" numbered="true" toc="default">
			<name>Terminology</name>
			<t>The following terms are used throughout this document to describe the
			roles and interactions of transport security protocols (some of which
			are also defined in <xref target="RFC8095" format="default"/>):</t>
			<dl>
			<dt>Transport Feature:</dt><dd>a specific end-to-end feature that the
			transport layer provides to an application. Examples include
			confidentiality, reliable delivery, ordered delivery, and
			message-versus-stream orientation.</dd>
			<dt>Transport Service:</dt><dd>a set of Transport Features, without an
			association to any given framing protocol, that provides
			functionality to an application.</dd>
			<dt>Transport Services system:</dt><dd>a software component that exposes
			an
			interface to different Transport Services to an application.</dd>
			<dt>Transport Protocol:</dt><dd>an implementation that provides one or m
			ore
			different Transport Services using a specific framing and header
			format on the wire. A Transport Protocol services an application,
			whether directly or in conjunction with a security protocol.</dd>
			<dt>Application:</dt><dd>an entity that uses a transport protocol for
			end-to-end delivery of data across the network. This may also be an
			upper layer protocol or tunnel encapsulation.</dd>
			<dt>Security Protocol:</dt><dd>a defined network protocol that implement
			s one
			or more security features, such as authentication, encryption, key
			generation, session resumption, and privacy. Security protocols may be
			used alongside transport protocols, and in combination with other
			security protocols when appropriate.</dd>
			<dt>Handshake Protocol:</dt><dd>a protocol that enables peers to validat
			e each
			other and to securely establish shared cryptographic context.</dd>
			<dt>Record:</dt><dd>framed protocol messages.</dd>
			<dt>Record Protocol:</dt><dd>a security protocol that allows data to be
			divided into manageable blocks and protected using shared
			cryptographic context.</dd>
			<dt>Session:</dt><dd>an ephemeral security association between
			applications.</dd>
			<dt>Connection:</dt><dd>the shared state of two or more endpoints that
			persists across messages that are transmitted between these
			endpoints. A connection is a transient participant of a session, and a
			session generally lasts between connection instances.</dd>
			<dt>Peer:</dt><dd>an endpoint application party to a session.</dd>
			<dt>Client:</dt><dd>the peer responsible for initiating a session.</dd>
			<dt>Server:</dt><dd>the peer responsible for responding to a session ini
			tiation.</dd>
			</dl>
			</section>
			<section anchor="transport-security-protocol-descriptions" numbered="true" t
			oc="default">
			<name>Transport Security Protocol Descriptions</name>
			<t>This section contains brief transport and security descriptions of
			various security protocols currently used to protect data being sent
			over a network. These protocols are grouped based on where in the
			protocol stack they are implemented, which influences which parts of a
			packet they protect: Generic application payload, application payload
			for specific application-layer protocols, both application payload and
			transport headers, or entire IP packets.</t>
			<t>Note that not all security protocols can be easily categorized, e.g.,
			as some protocols can be used in different ways or in combination with
			other protocols. One major reason for this is that channel security
			protocols often consist of two components:</t>
			<ul spacing="normal">
			<li>A handshake protocol, which is responsible for negotiating parameter
			s, authenticating the
			endpoints, and establishing shared keys.</li>
			<li>A record protocol, which is used to encrypt traffic using keys and p
			arameters provided by the
			handshake protocol.</li>
			</ul>
			<t>For some protocols, such as tcpcrypt, these two components are
			tightly integrated. In contrast, for IPsec, these components are
			implemented in separate protocols: AH and the Encapsulating Security Paylo
			ad
			(ESP) are record protocols, which can use keys supplied by the handshake
			protocol Internet Key Exchange Protocol Version 2 (IKEv2), by other
			handshake protocols, or by manual configuration. Moreover, some
			protocols can be used in different ways: While the base TLS protocol as
			defined in <xref target="RFC8446" format="default"/> has an integrated
			handshake and record protocol, TLS or DTLS can also be used to negotiate
			keys for other protocols, as in DTLS-SRTP, or the handshake protocol can
			be used with a separate record layer, as in QUIC <xref
			target="I-D.ietf-quic-transport" format="default"/>.</t>
			<section anchor="application-payload-security-protocols" numbered="true" t
			oc="default">
			<name>Application Payload Security Protocols</name>
			<t>The following protocols provide security that protects application pa
			yloads sent over a
			transport. They do not specifically protect any headers used for transport-layer
			functionality.</t>
			<section anchor="tls" numbered="true" toc="default">
			<name>TLS</name>
			<t>TLS (Transport Layer Security) <xref target="RFC8446"
			format="default"/> is a common protocol used to establish a secure
			session between two endpoints. Communication over this session
			prevents "eavesdropping, tampering, and message forgery." TLS
			consists of a tightly coupled handshake and record protocol. The
			handshake protocol is used to authenticate peers, negotiate protocol
			options such as cryptographic algorithms, and derive
			session-specific keying material. The record protocol is used to
			marshal and, once the handshake has sufficiently progressed,
			encrypt data from one peer to the other. This data may contain
			handshake messages or raw application data.</t>
			</section>
			<section anchor="dtls" numbered="true" toc="default">
			<name>DTLS</name>
			<t>DTLS (Datagram Transport Layer Security) <xref target="RFC6347"
			format="default"/> <xref target="I-D.ietf-tls-dtls13"
			format="default"/> is based on TLS, but differs in that it is
			designed to run over unreliable datagram protocols like UDP instead
			of TCP. DTLS modifies the protocol to make sure it can still
			provide equivalent security guarantees to TLS with the exception of
			order protection/non-replayability. DTLS was designed to be as
			similar to TLS as possible, so this document assumes that all
			properties from TLS are carried over except where specified.</t>
			</section>
			</section>
			<section anchor="application-specific-security-protocols" numbered="true"
			toc="default">
			<name>Application-Specific Security Protocols</name>
			<t>The following protocols provide application-specific security by prot
			ecting
			application payloads used for specific use cases. Unlike the protocols above,
			these are not intended for generic application use.</t>
			<section anchor="secure-rtp" numbered="true" toc="default">
			<name>Secure RTP</name>
			<t>Secure RTP (SRTP) is a profile for RTP that provides confidentialit
			y,
			message authentication, and replay protection for RTP data packets
			and RTP control protocol (RTCP) packets <xref target="RFC3711" format="default"/
			>.
			SRTP provides a record layer only, and requires a separate handshake
			protocol to provide key agreement and identity management.</t>
			<t>The commonly used handshake protocol for SRTP is DTLS, in the form
			of
			DTLS-SRTP <xref target="RFC5764" format="default"/>. This is an extension to DT
			LS that negotiates
			the use of SRTP as the record layer and describes how to export keys
			for use with SRTP.</t>
			<t>ZRTP <xref target="RFC6189" format="default"/> is an alternative ke
			y agreement and identity management
			protocol for SRTP. ZRTP Key agreement is performed using a Diffie-Hellman
			key exchange that runs on the media path. This generates a shared secret
			that is then used to generate the master key and salt for SRTP.</t>
			</section>
			</section>
			<section anchor="transport-layer-security-protocols" numbered="true" toc="
			default">
			<name>Transport-Layer Security Protocols</name>
			<t>The following security protocols provide protection for both applicat
			ion payloads and
			headers that are used for Transport Services.</t>
			<section anchor="quic" numbered="true" toc="default">
			<name>IETF QUIC</name>
			<t>QUIC is a new standards-track transport protocol that runs over UDP
			, loosely based on Google's
			original proprietary gQUIC protocol <xref target="I-D.ietf-quic-transport" forma
			t="default"/> (See <xref target="gquic" format="default"/> for more details).
			The QUIC transport layer itself provides support for data confidentiality and in
			tegrity. This requires
			keys to be derived with a separate handshake protocol. A mapping for QUIC of TLS
			1.3 <xref target="I-D.ietf-quic-tls" format="default"/>
			has been specified to provide this handshake.</t>
			</section>
			<section anchor="gquic" numbered="true" toc="default">
			<name>Google QUIC</name>
			<t>Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
			designed and deployed by Google following experience from deploying
			SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
			known as "QUIC"; this document uses gQUIC to unambiguously
			distinguish it from the standards-track IETF QUIC. The proprietary
			technical forebear of IETF QUIC, gQUIC was originally designed with
			tightly integrated security and application data transport
			protocols.</t>
			</section>
			<section anchor="tcpcrypt" numbered="true" toc="default">
			<name>tcpcrypt</name>
			<t>Tcpcrypt <xref target="RFC8548" format="default"/> is a lightweight
			extension to the TCP protocol for opportunistic encryption. Applications may
			use tcpcrypt's unique session ID for further application-level authentication. A
			bsent this authentication,
			tcpcrypt is vulnerable to active attacks.</t>
			</section>
			<section anchor="minimalt" numbered="true" toc="default">
			<name>MinimaLT</name>
			<t>MinimaLT <xref target="MinimaLT" format="default"/> is a UDP-based
			transport security protocol designed to offer confidentiality,
			mutual authentication, DoS prevention, and connection mobility. One major
			goal of the protocol is to leverage existing protocols to obtain server-side con
			figuration
			information used to more quickly bootstrap a connection. MinimaLT uses a variant
			of TCP's
			congestion control algorithm.</t>
			</section>
			<section anchor="curvecp" numbered="true" toc="default">
			<name>CurveCP</name>
			<t>CurveCP <xref target="CurveCP" format="default"/> is a UDP-based
			transport security that, unlike many other security protocols, is
			based entirely upon public key algorithms. CurveCP provides its own
			reliability for application data as part of its protocol.</t>
			</section>
			</section>
			<section anchor="packet-security-protocols" numbered="true" toc="default">
			<name>Packet Security Protocols</name>
			<t>The following protocols provide protection for IP packets. These
			are generally used as tunnels, such as for Virtual Private Networks
			(VPNs). Often, applications will not interact directly with these
			protocols. However, applications that implement tunnels will interact
			directly with these protocols.</t>
			<section anchor="ipsec" numbered="true" toc="default">
			<name>IPsec</name>
			<t>IKEv2 <xref target="RFC7296" format="default"/> and ESP <xref
			target="RFC4303" format="default"/> together form the modern IPsec
			protocol suite that encrypts and authenticates IP packets, either
			for creating tunnels (tunnel-mode) or for direct transport
			connections (transport-mode). This suite of protocols separates out
			the key generation protocol (IKEv2) from the transport encryption
			protocol (ESP). Each protocol can be used independently, but this
			document considers them together, since that is the most common
			pattern.</t>
			</section>
			<section anchor="wireguard" numbered="true" toc="default">
			<name>WireGuard</name>
			<t>WireGuard <xref target="WireGuard" format="default"/> is an IP-laye
			r protocol designed as an alternative to IPsec
			for certain use cases. It uses UDP to encapsulate IP datagrams between peers.
			Unlike most transport security protocols, which rely on Public Key Infrastructur
			e (PKI)
			for peer authentication, WireGuard authenticates peers using pre-shared public k
			eys
			delivered out of band, each of which is bound to one or more IP addresses.
			Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, nego
			tiation,
			or cryptographic agility.</t>
			</section>
			<section anchor="openvpn" numbered="true" toc="default">
			<name>OpenVPN</name>
			<t>OpenVPN <xref target="OpenVPN" format="default"/> is a commonly use
			d protocol designed as an alternative to
			IPsec. A major goal of this protocol is to provide a VPN that is simple to
			configure and works over a variety of transports. OpenVPN encapsulates either
			IP packets or Ethernet frames within a secure tunnel and can run over either UDP
			or TCP.
			For key establishment, OpenVPN can either use TLS as a handshake protocol or use
			pre-shared keys.</t>
			</section>
			</section>
			</section>
			<section anchor="transport-interface" numbered="true" toc="default">
			<name>Transport Dependencies</name>
			<t>Across the different security protocols listed above, the primary depen
			dency on transport
			protocols is the presentation of data: either an unbounded stream of bytes, or f
			ramed
			messages. Within protocols that rely on the transport for message framing, most
			are
			built to run over transports that inherently provide framing, like UDP, but some
			also define
			how their messages can be framed over byte-stream transports.</t>
			<section anchor="reliable-byte-stream-transports" numbered="true" toc="def
			ault">
			<name>Reliable Byte-Stream Transports</name>
			<t>The following protocols all depend upon running on a transport protoc
			ol that provides
			a reliable, in-order stream of bytes. This is typically TCP.</t>
			<t>Application Payload Security Protocols:</t>
			<ul spacing="normal">
			<li>TLS</li>
			</ul>
			<t>Transport-Layer Security Protocols:</t>
			<ul spacing="normal">
			<li>tcpcrypt</li>
			</ul>
			</section>
			<section anchor="unreliable-datagram-transports" numbered="true" toc="defa
			ult">
			<name>Unreliable Datagram Transports</name>
			<t>The following protocols all depend on the transport protocol to provi
			de message framing
			to encapsulate their data. These protocols are built to run using UDP, and thus
			do not
			have any requirement for reliability. Running these protocols over a protocol th
			at
			does provide reliability will not break functionality but may lead to multiple l
			ayers
			of reliability if the security protocol is encapsulating other transport protoco
			l traffic.</t>
			<t>Application Payload Security Protocols:</t>
			<ul spacing="normal">
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>SRTP</li>
			</ul>
			<t>Transport-Layer Security Protocols:</t>
			<ul spacing="normal">
			<li>QUIC</li>
			<li>MinimaLT</li>
			<li>CurveCP</li>
			</ul>
			<t>Packet Security Protocols:</t>
			<ul spacing="normal">
			<li>IPsec</li>
			<li>WireGuard</li>
			<li>OpenVPN</li>
			</ul>
			<section anchor="datagram-protocols-with-defined-byte-stream-mappings" n
			umbered="true" toc="default">
			<name>Datagram Protocols with Defined Byte-Stream Mappings</name>
			<t>Of the protocols listed above that depend on the transport for mess
			age framing, some
			do have well-defined mappings for sending their messages over byte-stream transp
			orts
			like TCP.</t>
			<t>Application Payload Security Protocols:</t>
			<ul spacing="normal">
			<li>DTLS when used as a handshake protocol for SRTP <xref target="RF
			C7850" format="default"/></li>
			<li>ZRTP <xref target="RFC6189" format="default"/></li>
			<li>SRTP <xref target="RFC4571" format="default"/><xref target="RFC3
			711" format="default"/></li>
			</ul>
			<t>Packet Security Protocols:</t>
			<ul spacing="normal">
			<li>IPsec <xref target="RFC8229" format="default"/></li>
			</ul>
			</section>
			</section>
			<section anchor="transport-specific-dependencies" numbered="true" toc="def
			ault">
			<name>Transport-Specific Dependencies</name>
			<t>One protocol surveyed, tcpcrypt, has a direct dependency on a
			feature in the transport that is needed for its
			functionality. Specifically, tcpcrypt is designed to run on top of
			TCP and uses the TCP Encryption Negotiation Option (TCP-ENO) <xref
			target="RFC8547" format="default"/> to negotiate its protocol
			support.</t>
			<t>QUIC, CurveCP, and MinimaLT provide both transport functionality and
			security functionality. They
			depend on running over a framed protocol like UDP, but they add their own layers
			of
			reliability and other Transport Services. Thus, an application that uses one of
			these protocols
			cannot decouple the security from transport functionality.</t>
			</section>
			</section>
			<section anchor="application-interface" numbered="true" toc="default">
			<name>Application Interface</name>
			<t>This section describes the interface exposed by the security protocols
			described above.
			We partition these interfaces into
			pre-connection (configuration), connection, and post-connection interfaces, foll
			owing
			conventions in <xref target="I-D.ietf-taps-interface" format="default"/> and <xr
			ef target="I-D.ietf-taps-arch" format="default"/>.</t>
			<t>Note that not all protocols support each interface.
			The table in <xref target="interface-protocols-table" format="default"/> summari
			zes which protocol exposes which of the interfaces.
			In the following sections, we provide abbreviations of the interface names to us
			e in the summary table.</t>
			<section anchor="pre-connection-interfaces" numbered="true" toc="default">
			<name>Pre-connection Interfaces</name>
			<t>Configuration interfaces are used to configure the security protocols
			before a
			handshake begins or keys are negotiated.</t>
			<dl spacing="normal">
			<dt>Identities and Private Keys (IPK):</dt>
			<dd><t>The application can provide its identity, credentials (e.g.,
			certificates), and private keys, or mechanisms to access these, to
			the security protocol to use during handshakes.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>QUIC</li>
			<li>MinimaLT</li>
			<li>CurveCP</li>
			<li>IPsec</li>
			<li>WireGuard</li>
			<li>OpenVPN</li>
			</ul>
			</dd>
			<dt>Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) (ALG):</dt
			><dd><t>
			The application can choose the algorithms that are supported for key exchange,
			signatures, and ciphersuites.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>QUIC</li>
			<li>tcpcrypt</li>
			<li>MinimaLT</li>
			<li>IPsec</li>
			<li>OpenVPN</li>
			</ul>
			</dd>
			<dt>Extensions (EXT):</dt><dd><t>
			The application enables or configures extensions that are to be negotiated by
			the security protocol, such as Application-Layer Protocol Negotiation (ALPN) <xr
			ef target="RFC7301" format="default"/>.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>QUIC</li>
			</ul>
			</dd>
			<dt>Session Cache Management (CM):</dt><dd><t>The application provides the
			ability to save and retrieve session state (such as tickets,
			keying material, and server parameters) that may be used to resume
			the security session.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>QUIC</li>
			<li>tcpcrypt</li>
			<li>MinimaLT</li>
			</ul>
			</dd>
			<dt>Authentication Delegation (AD):</dt><dd><t>
			The application provides access to a separate module that will provide authentic
			ation,
			using the Extensible Authentication Protocol (EAP) <xref target="RFC3748" format
			="default"/> for example.
			</t>
			<ul spacing="normal">
			<li>IPsec</li>
			<li>tcpcrypt</li>
			</ul>
			</dd>
			<dt>Pre-Shared Key Import (PSKI):</dt><dd><t>
			Either the handshake protocol or the application directly can supply pre-shared
			keys for use
			in encrypting (and authenticating) communication with a peer.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>QUIC</li>
			<li>tcpcrypt</li>
			<li>MinimaLT</li>
			<li>IPsec</li>
			<li>WireGuard</li>
			<li>OpenVPN</li>
			</ul>
			</dd>
			</dl>
			</section>
			<section anchor="connection-interfaces" numbered="true" toc="default">
			<name>Connection Interfaces</name>
			<dl spacing="normal">
			<dt>Identity Validation (IV):</dt><dd><t>
			During a handshake, the security protocol will conduct identity validation of th
			e peer.
			This can offload validation or occur transparently to the application.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>QUIC</li>
			<li>MinimaLT</li>
			<li>CurveCP</li>
			<li>IPsec</li>
			<li>WireGuard</li>
			<li>OpenVPN</li>
			</ul>
			</dd>
			<dt>Source Address Validation (SAV):</dt><dd><t>
			The handshake protocol may interact with the transport protocol or application t
			o
			validate the address of the remote peer that has sent data. This involves sendin
			g a cookie
			exchange to avoid DoS attacks. (This list omits protocols that depend on TCP and
			therefore
			implicitly perform SAV.)
			</t>
			<ul spacing="normal">
			<li>DTLS</li>
			<li>QUIC</li>
			<li>IPsec</li>
			<li>WireGuard</li>
			</ul>
			</dd>
			</dl>
			</section>
			<section anchor="post-connection-interfaces" numbered="true" toc="default"
			>
			<name>Post-connection Interfaces</name>
			<dl spacing="normal">
			<dt>Connection Termination (CT):</dt><dd><t>
			The security protocol may be instructed to tear down its connection and session
			information.
			This is needed by some protocols, e.g., to prevent application data truncation a
			ttacks in
			which an attacker terminates an underlying insecure connection-oriented protocol
			to terminate
			the session.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>ZRTP</li>
			<li>QUIC</li>
			<li>tcpcrypt</li>
			<li>MinimaLT</li>
			<li>IPsec</li>
			<li>OpenVPN</li>
			</ul>
			</dd>
			<dt>Key Update (KU):</dt><dd><t>
			The handshake protocol may be instructed to update its keying material, either
			by the application directly or by the record protocol sending a key expiration e
			vent.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>QUIC</li>
			<li>tcpcrypt</li>
			<li>MinimaLT</li>
			<li>IPsec</li>
			</ul>
			</dd>
			<dt>Shared Secret Key Export (SSKE):</dt><dd><t>
			The handshake protocol may provide an interface for producing shared secrets for
			application-specific uses.
			</t>
			<ul spacing="normal">
			<li>TLS</li>
			<li>DTLS</li>
			<li>tcpcrypt</li>
			<li>IPsec</li>
			<li>OpenVPN</li>
			<li>MinimaLT</li>
			</ul>
			</dd>
			<dt>Key Expiration (KE):</dt><dd><t>The record protocol can signal that its
			keys are expiring due to reaching a time-based deadline or a
			use-based deadline (number of bytes that have been encrypted with
			the key). This interaction is often limited to signaling between
			the record layer and the handshake layer.
			</t>
			<ul spacing="normal">
			<li>IPsec</li>
			</ul>
			</dd>
			<dt>Mobility Events (ME):</dt><dd><t> The record protocol can be signaled that
			it is being migrated to another transport or interface due to connection
			mobility, which may reset address and state validation and induce state
			changes such as use of a new Connection Identifier (CID).
			</t>
			<ul spacing="normal">
			<li>DTLS (version 1.3 only <xref target="I-D.ietf-tls-dtls13" form
			at="default"/>)</li>
			<li>QUIC</li>
			<li>MinimaLT</li>
			<li>CurveCP</li>
			<li>IPsec <xref target="RFC4555" format="default"/></li>
			<li>WireGuard</li>
			</ul>
			</dd>
			</dl>
			</section>
			<section anchor="interface-protocols-table" numbered="true" toc="default">
			<name>Summary of Interfaces Exposed by Protocols</name>
			<t>The following table summarizes which protocol exposes which interface
			.</t>
			<table align="center">
			<thead>
			<tr>
			<th align="left">Protocol</th>
			<th align="center">IPK</th>
			<th align="center">ALG</th>
			<th align="center">EXT</th>
			<th align="center">CM</th>
			<th align="center">AD</th>
			<th align="center">PSKI</th>
			<th align="center">IV</th>
			<th align="center">SAV</th>
			<th align="center">CT</th>
			<th align="center">KU</th>
			<th align="center">SSKE</th>
			<th align="center">KE</th>
			<th align="center">ME</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left">TLS</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			</tr>
			<tr>
			<td align="left">DTLS</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			</tr>
			<tr>
			<td align="left">ZRTP</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			</tr>
			<tr>
			<td align="left">QUIC</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			</tr>
			<tr>
			<td align="left">tcpcrypt</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			</tr>
			<tr>
			<td align="left">MinimaLT</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			</tr>
			<tr>
			<td align="left">CurveCP</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			</tr>
			<tr>
			<td align="left">IPsec</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			</tr>
			<tr>
			<td align="left">WireGuard</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			</tr>
			<tr>
			<td align="left">OpenVPN</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">x</td>
			<td align="center">&nbsp;</td>
			<td align="center">&nbsp;</td>
			</tr>
			</tbody>
			</table>
			<t>x = Interface is exposed<br/>
			(blank) = Interface is not exposed</t>
			</section>
			</section>
			<section anchor="iana-considerations" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
			</section>
			<section anchor="security-considerations" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>This document summarizes existing transport security protocols and thei
			r interfaces.
			It does not propose changes to or recommend usage of reference protocols. Moreov
			er,
			no claims of security and privacy properties beyond those guaranteed by the prot
			ocols
			discussed are made. For example, metadata leakage via timing side channels and t
			raffic
			analysis may compromise any protocol discussed in this survey. Applications usin
			g
			Security Interfaces should take such limitations into consideration when using a
			particular
			protocol implementation.</t>
			</section>
			<section anchor="privacy-considerations" numbered="true" toc="default">
			<name>Privacy Considerations</name>
			<t>Analysis of how features improve or degrade privacy is intentionally om
			itted from this survey.
			All security protocols surveyed generally improve privacy by using encryption to
			reduce information
			leakage. However, varying amounts of metadata remain in the clear across each
			protocol. For example, client and server certificates are sent in cleartext in T
			LS
			1.2 <xref target="RFC5246" format="default"/>, whereas they are encrypted in TLS
			1.3 <xref target="RFC8446" format="default"/>. A survey of privacy
			features, or lack thereof, for various security protocols could be addressed in
			a
			separate document.</t>
			</section>
			</middle>
			<back>
			<displayreference target="I-D.ietf-taps-arch" to="TAPS-ARCH"/>
			<displayreference target="I-D.ietf-quic-transport" to="QUIC-TRANSPORT"/>
			<displayreference target="I-D.ietf-tls-dtls13" to="DTLS-1.3"/>
			<displayreference target="I-D.ietf-quic-tls" to="QUIC-TLS"/>
			<displayreference target="I-D.ietf-taps-interface" to="TAPS-INTERFACE"/>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8095.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4253.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5641.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2385.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8548.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7850.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4571.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8229.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8547.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6189.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4555.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.
			xml"/>
			ckrefs
			<reference anchor="WireGuard" target="https://www.wireguard.com/papers/wir
			eguard.pdf">
			<front>
			<title>WireGuard: Next Generation Kernel Network Tunnel</title>
			<author initials="J" surname="Donenfeld">
			<organization>WireGuard</organization>
			</author>
			</front>
			</reference>
			<reference anchor="ALTS" target="https://cloud.google.com/security/encrypt
			ion-in-transit/application-layer-transport-security/">
			<front>
			<title>Application Layer Transport Security</title>
			<author initials="C" surname="Ghali">
			<organization/>
			</author>
			<author initials="A" surname="Stubblefield">
			<organization/>
			</author>
			<author initials="E" surname="Knapp">
			<organization/>
			</author>
			<author initials="J" surname="Li">
			<organization/>
			</author>
			<author initials="B" surname="Schmidt">
			<organization/>
			</author>
			<author initials="J" surname="Boeuf">
			<organization/>
			</author>
			</front>
			</reference>
			<reference anchor="CurveCP" target="https://curvecp.org/">
			<front>
			<title>CurveCP: Usable security for the Internet</title>
			<author initials="D" surname="Bernstein">
			<organization>CurveCP</organization>
			</author>
			</front>
			</reference>
			<reference anchor="MinimaLT" target="https://dl.acm.org/citation.cfm?id=25
			16737">
			<front>
			<title>MinimaLT: minimal-latency networking through better security</t
			itle>
			<author initials="W" surname="Petullo">
			<organization>United States Military Academy, West Point, NY, USA</o
			rganization>
			</author>
			<author initials="X" surname="Zhang">
			<organization>University of Illinois at Chicago, Chicago, IL, USA</o
			rganization>
			</author>
			<author initials="J" surname="Solworth">
			<organization>University of Illinois at Chicago, Chicago, IL, USA</o
			rganization>
			</author>
			<author initials="D" surname="Bernstein">
			<organization>University of Illinois at Chicago, Chicago, IL, USA</o
			rganization>
			</author>
			<author initials="T" surname="Lange">
			<organization>TU Eindhoven, Eindhoven, Netherlands</organization>
			</author>
			</front>
			<seriesInfo name="DOI" value="10.1145/2508859.2516737"/>
			</reference>
			<reference anchor="OpenVPN" target="https://openvpn.net/community-resource
			s/openvpn-cryptographic-layer/">
			<front>
			<title>OpenVPN cryptographic layer</title>
			<author>
			<organization>OpenVPN</organization>
			</author>
			</front>
			</reference>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ta
			ps-arch.xml"/>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-qu
			ic-transport.xml"/>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tl
			s-dtls13.xml"/>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-qu
			ic-tls.xml"/>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ta
			ps-interface.xml"/>
			</references>
			<section anchor="acknowledgments" numbered="false" toc="default">
			<name>Acknowledgments</name>
			<t>The authors would like to thank <contact fullname="Bob Bradley"/>,
			<contact fullname="Frederic Jacobs"/>, <contact fullname="Mirja
			Kühlewind"/>, <contact fullname="Yannick Sierra"/>, <contact
			fullname="Brian Trammell"/>, and <contact fullname="Magnus Westerlund"/>
			for their input and feedback on this document.</t>
			</section>
			</back>
			</rfc>
End of changes. 1 change blocks.
	lines changed or deleted		lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/