diff options
Diffstat (limited to 'doc/rfc/rfc8922.txt')
| -rw-r--r-- | doc/rfc/rfc8922.txt | 1044 |
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 |