RFC 8922

A Survey of the Interaction between Security Protocols and Transport Services

📅 published October 2020, from ietf

RFC 8922: A Survey of the Interaction between Security Protocols and Transport Services ✨

  • Stream and organisation: IETF (Internet Engineering Task Force) 💜
  • Category: Informational 🎀
  • Date: October 2020 🌸
  • ISSN: 2070-1721
  • Authors: T. Enghardt (TU Berlin), T. Pauly (Apple Inc.), C. Perkins (University of Glasgow), K. Rose (Akamai Technologies, Inc.), C. Wood (Cloudflare) 🫶
  • Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🦋

Abstract

okay so this doc is a survey of security protocols that are commonly used or just plain notable 🔐, and it's especially focused on how they interact and integrate with applications and transport protocols 💅. The goal is to supplement the work of defining and cataloguing Transport Services by spelling out the interfaces you need in order to add security protocols ✨. It's not limited to protocols made inside the IETF, and the ones included are 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's published for informational purposes 🧚

it's a product of the IETF, so it represents the consensus of the IETF community 👑. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💖. Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈.

for info on the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8922 🍓.

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) as they stand on the publication date 📜. Please read these carefully, because they spell out your rights and restrictions for 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 they come 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 were already catalogued in [RFC8095] 📚. This document builds on that work by surveying commonly used and notable network security protocols 🔐, and by identifying the interfaces between these protocols and both transport protocols and applications 🦋. It looks at 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, you get a brief description 📝. Then Section 4 covers the interfaces between these protocols and transports, and Section 5 covers the interfaces between these protocols and applications 🎀.

a Transport Services system exposes an interface so applications can reach various (secure) transport protocol features 💅. The security protocols in this survey are a superset of the 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 like (D)TLS are included, and so are non-standard protocols like gQUIC, even though they overlap in features 🌈. That's why this survey isn't limited to protocols developed inside the IETF 🙌. Anything outside this candidate set that doesn't offer new features gets left out 🙈. For example, newer protocols like WireGuard make unique design choices that have implications for, and limitations on, application usage ⭐. By contrast, protocols like secure shell (SSH) [RFC4253], GRE [RFC2890], the Layer 2 Tunneling Protocol (L2TP) [RFC5641], and Application Layer Transport Security (ALTS) [ALTS] are omitted, because they don't provide interfaces considered unique 💀.

authentication-only protocols like 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 the TCP MD5 "signature" options specified in [RFC2385].) One primary use case of TCP-AO is protecting BGP connections 🛡️. AH similarly adds per-datagram authentication and integrity, along with replay protection 🧩. Even with these improvements, neither protocol sees general use, and both lack critical properties that matter for emerging transport security protocols, like confidentiality and privacy protections 😭. So those protocols get left out too 🫠.

this document only surveys point-to-point protocols, and multicast protocols are out of scope 📍.

1.1. Goals

this survey is meant 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, so software can easily adopt new protocols that provide similar feature sets 🦋. Surveying the dependencies security protocols have on transport protocols can guide implementations in figuring out which transport protocols are appropriate 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 offering a reliable stream of bytes 🌊.

defining the common interfaces that security protocols provide to applications also lets interfaces be designed so common functionality can use the same APIs 🎀. For example, many security protocols that provide authentication let the application take part in peer identity validation 🪪. So any interface for using a secure transport protocol stack needs to let applications perform this action during connection establishment 🤝.

1.2. Non-goals

this survey does similar analysis to what was done for transport protocols in [RFC8095], but it's important to notice that using security protocols requires more consideration 🧠.

it is not a goal to let software implementations 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 😬. So any implementation needs to only use the set of protocols and algorithms that applications request or that a system policy allows 🔐.

different security protocols can also use incompatible notions of peer identity, authentication, and cryptographic options 🙃. It's not a goal to identify a common set of representations for these concepts 🙅‍♀️.

the protocols surveyed here are a superset of the functionality and features a Transport Services system may need to support 🌈. This document doesn't list all the transport protocols a Transport Services system may need to implement, and it doesn't mandate that a Transport Services 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 so the features can be configured 🎀.

2. Terminology ✨

okay bestie, let's get the vocab down first 💅 these terms show up everywhere in this doc, and [RFC8095] uses some of them too, so no mixing them up 🫶

Transport Feature: a specific end-to-end feature the transport layer gives an app 🎀 Examples are confidentiality, reliable delivery, ordered delivery, and whether it's message-oriented or stream-oriented 🌊

Transport Service: a set of Transport Features that isn't tied to any particular framing protocol, and that gives an app its functionality 🧁

Transport Services system: a software component that shows an app an interface to different Transport Services 🔌

Transport Protocol: an implementation that provides one or more Transport Services using a specific framing and header format on the wire 🦋 It services an app, either on its own or together with a security protocol 🤝

Application: an entity that uses a transport protocol for end-to-end delivery of data across the network 📱 This can also be an upper layer protocol or a tunnel encapsulation 🎁

Security Protocol: a defined network protocol that implements one or more security features, like authentication, encryption, key generation, session resumption, and privacy 🔐 Security protocols can be used alongside transport protocols, and combined with other security protocols when it makes sense 💜

Handshake Protocol: a protocol that lets peers validate each other and securely set up shared cryptographic context 🤝✨

Record: framed protocol messages 📦

Record Protocol: a security protocol that lets data get divided into manageable blocks, which are then protected using shared cryptographic context 🧱

Session: an ephemeral (short-lived) security association between applications 🦋

Connection: the shared state of two or more endpoints that persists across the messages sent between them 🔗 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 starting a session 🚀

Server: the peer responsible for responding when a session gets initiated 🏠

3. Transport Security Protocol Descriptions 🛡️

okay so this section is a quick tour of the security protocols people use to protect data going over a network 🌐 They're grouped by where they sit in the protocol stack, because that decides 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 📦

Not every security protocol fits neatly into one box, though 🙈 Some can be used in different ways, or stacked with other protocols. A big reason is that channel security protocols are often made 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, like tcpcrypt, these two components are tightly integrated 💞 But for IPsec, they're separate protocols 🧩 AH and the Encapsulating Security Payload (ESP) are record protocols, and they can use keys supplied by the handshake protocol Internet Key Exchange Protocol Version 2 (IKEv2), by other handshake protocols, or by manual configuration ⚙️ Some protocols are also flexible about how they're used 🤸‍♀️ The base TLS protocol as defined in [RFC8446] has an integrated handshake and record protocol, but TLS or DTLS can also be used to negotiate keys for other protocols, like DTLS-SRTP 🎶 Or the handshake protocol can be paired with a separate record layer, like in QUIC [QUIC-TRANSPORT] 🌸

3.1. Application Payload Security Protocols 🎀

These protocols give security that protects application payloads sent over a transport 💌 They don't specifically protect any headers used for transport-layer functionality 🙅‍♀️

3.1.1. TLS

TLS (Transport Layer Security) [RFC8446] is a super common protocol for setting up a secure session between two endpoints 🔐 Communication over that session prevents "eavesdropping, tampering, and message forgery." 🚫👀 TLS is made of a tightly coupled handshake and record protocol 💕 The handshake protocol authenticates peers, negotiates protocol options like cryptographic algorithms, and derives session-specific keying material 🗝️ The record protocol marshals data and, once the handshake has progressed enough, encrypts it from one peer to the other 📬 That data can include handshake messages or raw application data 🍓

3.1.2. DTLS

DTLS (Datagram Transport Layer Security) [RFC6347] [DTLS-1.3] is based on TLS, but it's designed to run over unreliable datagram protocols like UDP instead of TCP 🌊 DTLS changes the protocol so it can still provide security guarantees equivalent 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 carry over, except where specified 🧚

3.2. Application-Specific Security Protocols 🦄

These protocols give application-specific security by protecting application payloads used for specific use cases 🎯 Unlike the protocols above, these aren't meant 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 only provides a record layer, and it requires a separate handshake protocol to handle key agreement and identity management 🤝

The commonly used handshake protocol for SRTP is DTLS, in the form of DTLS-SRTP [RFC5764] 🎶 It's an extension to DTLS that negotiates the use of SRTP as the record layer, and it 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 runs a Diffie-Hellman key exchange on the media path 🌈 That generates a shared secret, which is then used to make the master key and salt for SRTP 🧂

3.3. Transport-Layer Security Protocols 🚇

These security protocols protect both application payloads and the headers that are used for Transport Services 💖

3.3.1. IETF QUIC

QUIC is a new standards-track transport protocol that runs over UDP 🚀 It's loosely based on Google's original proprietary gQUIC protocol [QUIC-TRANSPORT] (see Section 3.3.2 for more details) 🦋 The QUIC transport layer itself supports data confidentiality and integrity 🔒 That requires keys to be derived with a separate handshake protocol, and a mapping for QUIC of TLS 1.3 [QUIC-TLS] has been specified to provide that handshake 🤝

3.3.2. Google QUIC

Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol that Google designed and deployed, building on experience from deploying SPDY, the proprietary predecessor to HTTP/2 🌟 It was originally called "QUIC," but this document uses gQUIC to tell it apart from the standards-track IETF QUIC 🏷️ As 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 🆔 Without that authentication, tcpcrypt is vulnerable to active attacks 😭 Be careful with this one, babe ⚠️

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 is to reuse existing protocols to get server-side configuration information, which is used to bootstrap a connection more quickly ⚡ MinimaLT uses a variant of TCP's congestion control algorithm 🌊

3.3.5. CurveCP

CurveCP [CurveCP] is a UDP-based transport security protocol that, unlike many other security protocols, is based entirely on public key algorithms 🗝️ CurveCP provides its own reliability for application data as part of its protocol 💪

3.4. Packet Security Protocols 📦

These protocols protect IP packets 🛡️ They're generally used as tunnels, like for Virtual Private Networks (VPNs) 🕳️ Applications often don't interact with these protocols directly 🙈 But applications that implement tunnels will interact with them directly 🎀

3.4.1. IPsec

IKEv2 [RFC7296] and ESP [RFC4303] together make up the modern IPsec protocol suite, which encrypts and authenticates IP packets 🔐 They can be used either to create tunnels (tunnel-mode) or for direct transport connections (transport-mode) 🚇 The suite separates 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's 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 📨 Most transport security protocols rely on Public Key Infrastructure (PKI) for peer authentication, but WireGuard authenticates peers using pre-shared public keys delivered out of band, and each key is bound to one or more IP addresses 🔑 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 is to provide a VPN that's simple to configure and works over a variety of transports 🪄 OpenVPN encapsulates either IP packets or Ethernet frames inside a secure tunnel, and it can run over either UDP or TCP 🚋 For key establishment, OpenVPN can use TLS as a handshake protocol or use pre-shared keys 🗝️

4. Transport Dependencies 🔗

okay so across all the security protocols above, the main thing they need from the transport is how the data is presented: either an unbounded stream of bytes, or framed messages 🌊📦 Protocols that rely on the transport for message framing are mostly built to run over transports that already provide framing, like UDP 🫶 Some also define how their messages can be framed over byte-stream transports 🧵

4.1. Reliable Byte-Stream Transports 🧵

The following protocols all depend on running over a transport protocol that provides a reliable, in-order stream of bytes 💌 That's typically TCP 🌷

Application Payload Security Protocols:

  • TLS 🔐

Transport-Layer Security Protocols:

  • tcpcrypt 💖

4.2. Unreliable Datagram Transports 🦋

okay bestie, this group of protocols all count on the transport to do message framing so they can wrap up their data 📦. They're built to run over UDP, so they don't need reliability at all 🙈. Running them over something that is reliable won't break anything ✨, but it can stack up multiple layers of reliability, which gets messy if the security protocol is wrapping other transport 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 🌈

so, of the protocols above that rely on the transport for framing, some do have well-defined ways to send their messages over byte-stream transports like TCP 🧚. It's giving flexibility, periodt 💅.

Application Payload Security Protocols:

Packet Security Protocols:

4.3. Transport-Specific Dependencies 🎀

one protocol we looked at, tcpcrypt, has a direct dependency on a transport feature it needs to actually function 👑. 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 are giving both transport functionality and security functionality 🫶. They rely on running over a framed protocol like UDP, but they add their own layers of reliability and other Transport Services 💖. So an application using one of these can't pull the security apart from the transport stuff 😭.

5. Application Interface ✨

this section is all about the interface the security protocols above expose 💜. We split these into pre-connection (configuration), connection, and post-connection interfaces, following the conventions in [TAPS-INTERFACE] and [TAPS-ARCH] 🦋.

heads up, not every protocol supports every interface 🙈. The table in Section 5.4 summarizes who exposes what 💅. Below, we give short abbreviations for each interface name so the summary table stays readable 🍓.

5.1. Pre-connection Interfaces 🌸

these are the configuration interfaces, used to set up the security protocols before a handshake starts or keys get negotiated 🧚.

Identities and Private Keys (IPK): the application can hand over its identity, credentials (like certificates), and private keys, or mechanisms to access them, for 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 pick which algorithms are supported for key exchange, signatures, and ciphersuites ✨.

  • TLS
  • DTLS
  • ZRTP
  • QUIC
  • tcpcrypt
  • MinimaLT
  • IPsec
  • OpenVPN

Extensions (EXT): the application turns on or configures extensions that the security protocol will negotiate, like Application-Layer Protocol Negotiation (ALPN) [RFC7301] 🎀.

  • TLS
  • DTLS
  • QUIC

Session Cache Management (CM): the application can save and retrieve session state (things like tickets, keying material, and server parameters) that can be used to resume the security session 💾.

  • TLS
  • DTLS
  • ZRTP
  • QUIC
  • tcpcrypt
  • MinimaLT

Authentication Delegation (AD): the application gets access to a separate module that handles authentication, using the Extensible Authentication Protocol (EAP) [RFC3748] for example 👑.

  • IPsec
  • tcpcrypt

Pre-Shared Key Import (PSKI): either the handshake protocol or the application itself can supply pre-shared keys for 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 checks the identity of the peer 🕵️. This can be offloaded, or it can happen quietly without the application noticing 🫧.

  • TLS
  • DTLS
  • ZRTP
  • QUIC
  • MinimaLT
  • CurveCP
  • IPsec
  • WireGuard
  • OpenVPN

Source Address Validation (SAV): the handshake protocol may work with the transport protocol or the application to validate the address of the remote peer that sent data 🌈. This involves a cookie exchange to avoid DoS attacks 🛡️. (This list leaves out protocols that depend on TCP, since they implicitly do SAV already 💅.)

  • DTLS
  • QUIC
  • IPsec
  • WireGuard

5.3. Post-connection Interfaces 🌙

Connection Termination (CT): the security protocol can be told to tear down its connection and session info 🧹. Some protocols need this, for example to stop application data truncation attacks, where an attacker kills an underlying insecure connection-oriented protocol just to end the session 💀.

  • TLS
  • DTLS
  • ZRTP
  • QUIC
  • tcpcrypt
  • MinimaLT
  • IPsec
  • OpenVPN

Key Update (KU): the handshake protocol can be told 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 offer 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, either because a time-based deadline or a use-based deadline (a number of bytes encrypted with the key) has been reached ⏰. This 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's being moved to another transport or interface because of connection mobility 📱. That can reset address and state validation and cause state changes, like switching to 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 📋

here's the cheat sheet 🌸. It shows 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 🌷, so nothing to register here, bestie 🫶.

7. Security Considerations 🚨

this document sums up existing transport security protocols and their interfaces 🔍. It doesn't propose changes to the reference protocols or recommend using any of them 🙅. It also doesn't claim any security or privacy properties beyond what the discussed protocols already guarantee 🔒. For example, metadata leakage through timing side channels and traffic analysis may affect any protocol in this survey 😱👀. Applications using Security Interfaces should take these limitations into account when they use a particular protocol implementation 🚨💜.

8. Privacy Considerations 🫣

this survey intentionally skips analysis of how features help or hurt privacy 🙈. All the security protocols covered generally improve privacy by using encryption to cut down on information leakage ✨. But different amounts of metadata still show up in the clear depending on the protocol 🕶️. For example, client and server certificates are sent in cleartext in TLS 1.2 [RFC5246], but they're encrypted in TLS 1.3 [RFC8446] 🔐🥹. A survey of privacy features (or the lack of them) for different security protocols could be covered in a separate document 📚💖.

9. Informative References ✨

okay bestie, this is the reading list 📚 every single one of these is a source the spec leans on, so I'm keeping the full details for each. no skipping! 💅

Acknowledgments 🫶

the authors want to give a huge thank-you to Bob Bradley, Frederic Jacobs, Mirja Kühlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund 💜 for their input and feedback on this document. you're the real MVPs 👑

Authors' Addresses 🎀

Theresa Enghardt 🌸

Theresa Enghardt
TU Berlin
Marchstr. 23
10587 Berlin
Germany

Email: ietf@tenghardt.net

Tommy Pauly 🦋

Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America

Email: tpauly@apple.com

Colin Perkins 🍓

Colin Perkins
University of Glasgow
School of Computing Science
Glasgow
G12 8QQ
United Kingdom

Email: csp@csperkins.org

Kyle Rose 🧚

Kyle Rose
Akamai Technologies, Inc.
150 Broadway
Cambridge, MA 02144
United States of America

Email: krose@krose.org

Christopher A. Wood 🌈

Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco,
United States of America

Email: caw@heapingbits.net
📦 where this page comes from