doc: Add RFC documents

1 files changed, 1044 insertions, 0 deletions

diff --git a/doc/rfc/rfc8922.txt b/doc/rfc/rfc8922.txt
new file mode 100644
index 0000000..0d36aa9
--- /dev/null
+++ b/doc/rfc/rfc8922.txt
@@ -0,0 +1,1044 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       T. Enghardt
+Request for Comments: 8922                                     TU Berlin
+Category: Informational                                         T. Pauly
+ISSN: 2070-1721                                               Apple Inc.
+                                                              C. Perkins
+                                                   University of Glasgow
+                                                                 K. Rose
+                                               Akamai Technologies, Inc.
+                                                                 C. Wood
+                                                              Cloudflare
+                                                            October 2020
+
+
+  A Survey of the Interaction between Security Protocols and Transport
+                                Services
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8922.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Goals
+     1.2.  Non-goals
+   2.  Terminology
+   3.  Transport Security Protocol Descriptions
+     3.1.  Application Payload Security Protocols
+       3.1.1.  TLS
+       3.1.2.  DTLS
+     3.2.  Application-Specific Security Protocols
+       3.2.1.  Secure RTP
+     3.3.  Transport-Layer Security Protocols
+       3.3.1.  IETF QUIC
+       3.3.2.  Google QUIC
+       3.3.3.  tcpcrypt
+       3.3.4.  MinimaLT
+       3.3.5.  CurveCP
+     3.4.  Packet Security Protocols
+       3.4.1.  IPsec
+       3.4.2.  WireGuard
+       3.4.3.  OpenVPN
+   4.  Transport Dependencies
+     4.1.  Reliable Byte-Stream Transports
+     4.2.  Unreliable Datagram Transports
+       4.2.1.  Datagram Protocols with Defined Byte-Stream Mappings
+     4.3.  Transport-Specific Dependencies
+   5.  Application Interface
+     5.1.  Pre-connection Interfaces
+     5.2.  Connection Interfaces
+     5.3.  Post-connection Interfaces
+     5.4.  Summary of Interfaces Exposed by Protocols
+   6.  IANA Considerations
+   7.  Security Considerations
+   8.  Privacy Considerations
+   9.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   Services and features provided by transport protocols have been
+   cataloged in [RFC8095].  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 Section 4 and the interfaces between
+   these protocols and applications in Section 5.
+
+   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
+   [TAPS-ARCH].  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)
+   [RFC4253], GRE [RFC2890], the Layer 2 Tunneling Protocol (L2TP)
+   [RFC5641], and Application Layer Transport Security (ALTS) [ALTS] are
+   omitted since they do not provide interfaces deemed unique.
+
+   Authentication-only protocols such as the TCP Authentication Option
+   (TCP-AO) [RFC5925] and the IPsec Authentication Header (AH) [RFC4302]
+   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 [RFC2385].)  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.
+
+   This document only surveys point-to-point protocols; multicast
+   protocols are out of scope.
+
+1.1.  Goals
+
+   This survey is intended to help identify the most common interface
+   surfaces between security protocols and transport protocols, and
+   between security protocols and applications.
+
+   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.
+
+   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.
+
+1.2.  Non-goals
+
+   While this survey provides similar analysis to that which was
+   performed for transport protocols in [RFC8095], it is important to
+   distinguish that the use of security protocols requires more
+   consideration.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+2.  Terminology
+
+   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 [RFC8095]):
+
+   Transport Feature:  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.
+
+   Transport Service:  a set of Transport Features, without an
+      association to any given framing protocol, that provides
+      functionality to an application.
+
+   Transport Services system:  a software component that exposes an
+      interface to different Transport Services to an application.
+
+   Transport Protocol:  an implementation that provides one or more
+      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.
+
+   Application:  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.
+
+   Security Protocol:  a defined network protocol that implements 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.
+
+   Handshake Protocol:  a protocol that enables peers to validate each
+      other and to securely establish shared cryptographic context.
+
+   Record:  framed protocol messages.
+
+   Record Protocol:  a security protocol that allows data to be divided
+      into manageable blocks and protected using shared cryptographic
+      context.
+
+   Session:  an ephemeral security association between applications.
+
+   Connection:  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.
+
+   Peer:  an endpoint application party to a session.
+
+   Client:  the peer responsible for initiating a session.
+
+   Server:  the peer responsible for responding to a session initiation.
+
+3.  Transport Security Protocol Descriptions
+
+   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.
+
+   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:
+
+   *  A handshake protocol, which is responsible for negotiating
+      parameters, authenticating the endpoints, and establishing shared
+      keys.
+
+   *  A record protocol, which is used to encrypt traffic using keys and
+      parameters provided by the handshake protocol.
+
+   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
+   Payload (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 [RFC8446] 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 [QUIC-TRANSPORT].
+
+3.1.  Application Payload Security Protocols
+
+   The following protocols provide security that protects application
+   payloads sent over a transport.  They do not specifically protect any
+   headers used for transport-layer functionality.
+
+3.1.1.  TLS
+
+   TLS (Transport Layer Security) [RFC8446] 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.
+
+3.1.2.  DTLS
+
+   DTLS (Datagram Transport Layer Security) [RFC6347] [DTLS-1.3] 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.
+
+3.2.  Application-Specific Security Protocols
+
+   The following protocols provide application-specific security by
+   protecting application payloads used for specific use cases.  Unlike
+   the protocols above, these are not intended for generic application
+   use.
+
+3.2.1.  Secure RTP
+
+   Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
+   message authentication, and replay protection for RTP data packets
+   and RTP control protocol (RTCP) packets [RFC3711].  SRTP provides a
+   record layer only, and requires a separate handshake protocol to
+   provide key agreement and identity management.
+
+   The commonly used handshake protocol for SRTP is DTLS, in the form of
+   DTLS-SRTP [RFC5764].  This is an extension to DTLS that negotiates
+   the use of SRTP as the record layer and describes how to export keys
+   for use with SRTP.
+
+   ZRTP [RFC6189] is an alternative key 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.
+
+3.3.  Transport-Layer Security Protocols
+
+   The following security protocols provide protection for both
+   application payloads and headers that are used for Transport
+   Services.
+
+3.3.1.  IETF QUIC
+
+   QUIC is a new standards-track transport protocol that runs over UDP,
+   loosely based on Google's original proprietary gQUIC protocol
+   [QUIC-TRANSPORT] (See Section 3.3.2 for more details).  The QUIC
+   transport layer itself provides support for data confidentiality and
+   integrity.  This requires keys to be derived with a separate
+   handshake protocol.  A mapping for QUIC of TLS 1.3 [QUIC-TLS] has
+   been specified to provide this handshake.
+
+3.3.2.  Google QUIC
+
+   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.
+
+3.3.3.  tcpcrypt
+
+   Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
+   opportunistic encryption.  Applications may use tcpcrypt's unique
+   session ID for further application-level authentication.  Absent this
+   authentication, tcpcrypt is vulnerable to active attacks.
+
+3.3.4.  MinimaLT
+
+   MinimaLT [MinimaLT] 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 configuration
+   information used to more quickly bootstrap a connection.  MinimaLT
+   uses a variant of TCP's congestion control algorithm.
+
+3.3.5.  CurveCP
+
+   CurveCP [CurveCP] 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.
+
+3.4.  Packet Security Protocols
+
+   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.
+
+3.4.1.  IPsec
+
+   IKEv2 [RFC7296] and ESP [RFC4303] 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.
+
+3.4.2.  WireGuard
+
+   WireGuard [WireGuard] is an IP-layer 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 Infrastructure (PKI) for
+   peer authentication, WireGuard authenticates peers using pre-shared
+   public keys 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, negotiation, or cryptographic
+   agility.
+
+3.4.3.  OpenVPN
+
+   OpenVPN [OpenVPN] is a commonly used 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.
+
+4.  Transport Dependencies
+
+   Across the different security protocols listed above, the primary
+   dependency on transport protocols is the presentation of data: either
+   an unbounded stream of bytes, or framed 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.
+
+4.1.  Reliable Byte-Stream Transports
+
+   The following protocols all depend upon running on a transport
+   protocol that provides a reliable, in-order stream of bytes.  This is
+   typically TCP.
+
+   Application Payload Security Protocols:
+
+   *  TLS
+
+   Transport-Layer Security Protocols:
+
+   *  tcpcrypt
+
+4.2.  Unreliable Datagram Transports
+
+   The following protocols all depend on the transport protocol to
+   provide 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 that does
+   provide reliability will not break functionality but may lead to
+   multiple layers of reliability if the security protocol is
+   encapsulating other transport protocol traffic.
+
+   Application Payload Security Protocols:
+
+   *  DTLS
+
+   *  ZRTP
+
+   *  SRTP
+
+   Transport-Layer Security Protocols:
+
+   *  QUIC
+
+   *  MinimaLT
+
+   *  CurveCP
+
+   Packet Security Protocols:
+
+   *  IPsec
+
+   *  WireGuard
+
+   *  OpenVPN
+
+4.2.1.  Datagram Protocols with Defined Byte-Stream Mappings
+
+   Of the protocols listed above that depend on the transport for
+   message framing, some do have well-defined mappings for sending their
+   messages over byte-stream transports like TCP.
+
+   Application Payload Security Protocols:
+
+   *  DTLS when used as a handshake protocol for SRTP [RFC7850]
+
+   *  ZRTP [RFC6189]
+
+   *  SRTP [RFC4571][RFC3711]
+
+   Packet Security Protocols:
+
+   *  IPsec [RFC8229]
+
+4.3.  Transport-Specific Dependencies
+
+   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) [RFC8547] to negotiate its protocol
+   support.
+
+   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.
+
+5.  Application Interface
+
+   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, following conventions in [TAPS-INTERFACE] and
+   [TAPS-ARCH].
+
+   Note that not all protocols support each interface.  The table in
+   Section 5.4 summarizes which protocol exposes which of the
+   interfaces.  In the following sections, we provide abbreviations of
+   the interface names to use in the summary table.
+
+5.1.  Pre-connection Interfaces
+
+   Configuration interfaces are used to configure the security protocols
+   before a handshake begins or keys are negotiated.
+
+   Identities and Private Keys (IPK):  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.
+
+      *  TLS
+
+      *  DTLS
+
+      *  ZRTP
+
+      *  QUIC
+
+      *  MinimaLT
+
+      *  CurveCP
+
+      *  IPsec
+
+      *  WireGuard
+
+      *  OpenVPN
+
+   Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
+   (ALG):  The application can choose the algorithms that are supported
+      for key exchange, signatures, and ciphersuites.
+
+      *  TLS
+
+      *  DTLS
+
+      *  ZRTP
+
+      *  QUIC
+
+      *  tcpcrypt
+
+      *  MinimaLT
+
+      *  IPsec
+
+      *  OpenVPN
+
+   Extensions (EXT):  The application enables or configures extensions
+      that are to be negotiated by the security protocol, such as
+      Application-Layer Protocol Negotiation (ALPN) [RFC7301].
+
+      *  TLS
+
+      *  DTLS
+
+      *  QUIC
+
+   Session Cache Management (CM):  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.
+
+      *  TLS
+
+      *  DTLS
+
+      *  ZRTP
+
+      *  QUIC
+
+      *  tcpcrypt
+
+      *  MinimaLT
+
+   Authentication Delegation (AD):  The application provides access to a
+      separate module that will provide authentication, using the
+      Extensible Authentication Protocol (EAP) [RFC3748] for example.
+
+      *  IPsec
+
+      *  tcpcrypt
+
+   Pre-Shared Key Import (PSKI):  Either the handshake protocol or the
+      application directly can supply pre-shared keys for use in
+      encrypting (and authenticating) communication with a peer.
+
+      *  TLS
+
+      *  DTLS
+
+      *  ZRTP
+
+      *  QUIC
+
+      *  tcpcrypt
+
+      *  MinimaLT
+
+      *  IPsec
+
+      *  WireGuard
+
+      *  OpenVPN
+
+5.2.  Connection Interfaces
+
+   Identity Validation (IV):  During a handshake, the security protocol
+      will conduct identity validation of the peer.  This can offload
+      validation or occur transparently to the application.
+
+      *  TLS
+
+      *  DTLS
+
+      *  ZRTP
+
+      *  QUIC
+
+      *  MinimaLT
+
+      *  CurveCP
+
+      *  IPsec
+
+      *  WireGuard
+
+      *  OpenVPN
+
+   Source Address Validation (SAV):  The handshake protocol may interact
+      with the transport protocol or application to validate the address
+      of the remote peer that has sent data.  This involves sending a
+      cookie exchange to avoid DoS attacks.  (This list omits protocols
+      that depend on TCP and therefore implicitly perform SAV.)
+
+      *  DTLS
+
+      *  QUIC
+
+      *  IPsec
+
+      *  WireGuard
+
+5.3.  Post-connection Interfaces
+
+   Connection Termination (CT):  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 attacks in which an attacker terminates an underlying
+      insecure connection-oriented protocol to terminate the session.
+
+      *  TLS
+
+      *  DTLS
+
+      *  ZRTP
+
+      *  QUIC
+
+      *  tcpcrypt
+
+      *  MinimaLT
+
+      *  IPsec
+
+      *  OpenVPN
+
+   Key Update (KU):  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 event.
+
+      *  TLS
+
+      *  DTLS
+
+      *  QUIC
+
+      *  tcpcrypt
+
+      *  MinimaLT
+
+      *  IPsec
+
+   Shared Secret Key Export (SSKE):  The handshake protocol may provide
+      an interface for producing shared secrets for application-specific
+      uses.
+
+      *  TLS
+
+      *  DTLS
+
+      *  tcpcrypt
+
+      *  IPsec
+
+      *  OpenVPN
+
+      *  MinimaLT
+
+   Key Expiration (KE):  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.
+
+      *  IPsec
+
+   Mobility Events (ME):  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).
+
+      *  DTLS (version 1.3 only [DTLS-1.3])
+
+      *  QUIC
+
+      *  MinimaLT
+
+      *  CurveCP
+
+      *  IPsec [RFC4555]
+
+      *  WireGuard
+
+5.4.  Summary of Interfaces Exposed by Protocols
+
+   The following table summarizes which protocol exposes which
+   interface.
+
+   +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
+   | Protocol  |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| SSKE |KE|ME|
+   +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
+   | TLS       | x | x  |  x  |x |  |  x   |x |     |x |x |  x   |  |  |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | DTLS      | x | x  |  x  |x |  |  x   |x |  x  |x |x |  x   |  |x |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | ZRTP      | x | x  |     |x |  |  x   |x |     |x |  |      |  |  |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | QUIC      | x | x  |  x  |x |  |  x   |x |  x  |x |x |      |  |x |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | tcpcrypt  |   | x  |     |x |x |  x   |  |     |x |x |  x   |  |  |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | MinimaLT  | x | x  |     |x |  |  x   |x |     |x |x |  x   |  |x |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | CurveCP   | x |    |     |  |  |      |x |     |  |  |      |  |x |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | IPsec     | x | x  |     |  |x |  x   |x |  x  |x |x |  x   |x |x |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | WireGuard | x |    |     |  |  |  x   |x |  x  |  |  |      |  |x |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+   | OpenVPN   | x | x  |     |  |  |  x   |x |     |x |  |  x   |  |  |
+   +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
+
+                                  Table 1
+
+   x = Interface is exposed
+   (blank) = Interface is not exposed
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  Security Considerations
+
+   This document summarizes existing transport security protocols and
+   their interfaces.  It does not propose changes to or recommend usage
+   of reference protocols.  Moreover, no claims of security and privacy
+   properties beyond those guaranteed by the protocols discussed are
+   made.  For example, metadata leakage via timing side channels and
+   traffic analysis may compromise any protocol discussed in this
+   survey.  Applications using Security Interfaces should take such
+   limitations into consideration when using a particular protocol
+   implementation.
+
+8.  Privacy Considerations
+
+   Analysis of how features improve or degrade privacy is intentionally
+   omitted 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 TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
+   [RFC8446].  A survey of privacy features, or lack thereof, for
+   various security protocols could be addressed in a separate document.
+
+9.  Informative References
+
+   [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/>.
+
+   [CurveCP]  Bernstein, D., "CurveCP: Usable security for the
+              Internet", <https://curvecp.org/>.
+
+   [DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+              Datagram Transport Layer Security (DTLS) Protocol Version
+              1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
+              dtls13-38, 29 May 2020,
+              <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.
+
+   [MinimaLT] Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and
+              T. Lange, "MinimaLT: minimal-latency networking through
+              better security", DOI 10.1145/2508859.2516737,
+              <https://dl.acm.org/citation.cfm?id=2516737>.
+
+   [OpenVPN]  OpenVPN, "OpenVPN cryptographic layer",
+              <https://openvpn.net/community-resources/openvpn-
+              cryptographic-layer/>.
+
+   [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
+              Work in Progress, Internet-Draft, draft-ietf-quic-tls-31,
+              24 September 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-tls-31>.
+
+   [QUIC-TRANSPORT]
+              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
+              and Secure Transport", Work in Progress, Internet-Draft,
+              draft-ietf-quic-transport-31, 24 September 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-transport-
+              31>.
+
+   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+              Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
+              1998, <https://www.rfc-editor.org/info/rfc2385>.
+
+   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
+              RFC 2890, DOI 10.17487/RFC2890, September 2000,
+              <https://www.rfc-editor.org/info/rfc2890>.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, DOI 10.17487/RFC3711, March 2004,
+              <https://www.rfc-editor.org/info/rfc3711>.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
+              <https://www.rfc-editor.org/info/rfc3748>.
+
+   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
+              January 2006, <https://www.rfc-editor.org/info/rfc4253>.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
+              DOI 10.17487/RFC4302, December 2005,
+              <https://www.rfc-editor.org/info/rfc4302>.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, DOI 10.17487/RFC4303, December 2005,
+              <https://www.rfc-editor.org/info/rfc4303>.
+
+   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
+              (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
+              <https://www.rfc-editor.org/info/rfc4555>.
+
+   [RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
+              and RTP Control Protocol (RTCP) Packets over Connection-
+              Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
+              2006, <https://www.rfc-editor.org/info/rfc4571>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5641]  McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol
+              Version 3 (L2TPv3) Extended Circuit Status Values",
+              RFC 5641, DOI 10.17487/RFC5641, August 2009,
+              <https://www.rfc-editor.org/info/rfc5641>.
+
+   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
+              Security (DTLS) Extension to Establish Keys for the Secure
+              Real-time Transport Protocol (SRTP)", RFC 5764,
+              DOI 10.17487/RFC5764, May 2010,
+              <https://www.rfc-editor.org/info/rfc5764>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <https://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC6189]  Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
+              Media Path Key Agreement for Unicast Secure RTP",
+              RFC 6189, DOI 10.17487/RFC6189, April 2011,
+              <https://www.rfc-editor.org/info/rfc6189>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <https://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+              Kivinen, "Internet Key Exchange Protocol Version 2
+              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+              2014, <https://www.rfc-editor.org/info/rfc7296>.
+
+   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
+              July 2014, <https://www.rfc-editor.org/info/rfc7301>.
+
+   [RFC7850]  Nandakumar, S., "Registering Values of the SDP 'proto'
+              Field for Transporting RTP Media over TCP under Various
+              RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016,
+              <https://www.rfc-editor.org/info/rfc7850>.
+
+   [RFC8095]  Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
+              Ed., "Services Provided by IETF Transport Protocols and
+              Congestion Control Mechanisms", RFC 8095,
+              DOI 10.17487/RFC8095, March 2017,
+              <https://www.rfc-editor.org/info/rfc8095>.
+
+   [RFC8229]  Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
+              of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
+              August 2017, <https://www.rfc-editor.org/info/rfc8229>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8547]  Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
+              Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
+              DOI 10.17487/RFC8547, May 2019,
+              <https://www.rfc-editor.org/info/rfc8547>.
+
+   [RFC8548]  Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
+              Q., and E. Smith, "Cryptographic Protection of TCP Streams
+              (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
+              <https://www.rfc-editor.org/info/rfc8548>.
+
+   [TAPS-ARCH]
+              Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
+              Perkins, C., Tiesel, P. S., and C. A. Wood, "An
+              Architecture for Transport Services", Work in Progress,
+              Internet-Draft, draft-ietf-taps-arch-08, 13 July 2020,
+              <https://tools.ietf.org/html/draft-ietf-taps-arch-08>.
+
+   [TAPS-INTERFACE]
+              Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
+              Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A.,
+              and T. Pauly, "An Abstract Application Layer Interface to
+              Transport Services", Work in Progress, Internet-Draft,
+              draft-ietf-taps-interface-09, 27 July 2020,
+              <https://tools.ietf.org/html/draft-ietf-taps-interface-
+              09>.
+
+   [WireGuard]
+              Donenfeld, J., "WireGuard: Next Generation Kernel Network
+              Tunnel", <https://www.wireguard.com/papers/wireguard.pdf>.
+
+Acknowledgments
+
+   The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
+   Kühlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
+   their input and feedback on this document.
+
+Authors' Addresses
+
+   Theresa Enghardt
+   TU Berlin
+   Marchstr. 23
+   10587 Berlin
+   Germany
+
+   Email: ietf@tenghardt.net
+
+
+   Tommy Pauly
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, California 95014
+   United States of America
+
+   Email: tpauly@apple.com
+
+
+   Colin Perkins
+   University of Glasgow
+   School of Computing Science
+   Glasgow
+   G12 8QQ
+   United Kingdom
+
+   Email: csp@csperkins.org
+
+
+   Kyle Rose
+   Akamai Technologies, Inc.
+   150 Broadway
+   Cambridge, MA 02144
+   United States of America
+
+   Email: krose@krose.org
+
+
+   Christopher A. Wood
+   Cloudflare
+   101 Townsend St
+   San Francisco,
+   United States of America
+
+   Email: caw@heapingbits.net