Draft: draft-ietf-taps-transport-security

Commentary: I just a bunch of text to fill out : Goal / non - goals Explain transport dependencies in more detail Group the protocols by layer 
 Proposed outline : Introduction Goals Non - goals Terminology Security Protocols ( short sentence descriptions , with reference ) Application - Specific Payload Security ( SRTP ) Application - Agnostic Payload Security ( TLS / DTLS ) Transport Security ( QUIC / tcpcrypt / MinimalT ) IP Security ( IKEv2 / OpenVPN / WireGuard ) Interface to Transport Stream ( reliable ) Datagram message framing ( unreliable or not ) Protocol - specific needs ( TCP - ENO ) Interface to Applications List application knobs , annotate which protocols support 
 I think we can close this . 
 Agree 
 Sounds really good to me on first read!This looks great .
Paragraph (version A):
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.  Moreover, this document defines
a minimal set of security features that a secure transport system
should provide.
Paragraph (version B):
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.
Paragraph (version A):
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 services and features a Transport Services system (a
system that provides a transport API) needs to provide in order to
add transport security.  It examines Transport Layer Security (TLS),
Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt,
Internet Key Exchange with Encapsulating Security Protocol (IKEv2 +
ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT.  For each
protocol, this document provides a brief description, the security
features it provides, and the dependencies it has on the underlying
transport.  This is followed by defining the set of transport
security features shared by these protocols.  The document groups
these security features into a minimal set of features, which every
secure transport system should provide in addition to the transport
features described in I-D.ietf-taps-minset, and additional optional
features, which may not be available in every secure transport
system.  Finally, the document distills the application and transport
interfaces provided by the transport security protocols.
Paragraph (version B):
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 services and features a Transport Services system (a
system that provides a transport API) needs to provide in order to
add transport security.  It examines Transport Layer Security (TLS),
Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt,
Internet Key Exchange with Encapsulating Security Protocol (IKEv2 +
ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT.  For each
protocol, this document provides a brief description, the
dependencies it has on the underlying transports, and the interfaces
provided to applications.
Paragraph (version A):
Selected protocols represent a superset of functionality and features
a Transport Services system may need to support, both internally and
externally (via an API) for applications I-D.ietf-taps-arch.
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
protocols such as Google QUIC, are both 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 important implications on applications, such as how to best
configure peer public keys and to delegate algorithm selection to the
system.  In contrast, protocols such as ALTS ALTS are omitted since
they do not represent features deemed unique.
Paragraph (version B):
Selected protocols represent a superset of functionality and features
a Transport Services system may need to support, both internally and
externally (via an API) for applications I-D.ietf-taps-arch.
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
protocols such as Google QUIC, are both 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 and limitations on application usage.  In
contrast, protocols such as ALTS ALTS are omitted since they do not
provide interfaces deemed unique.
Paragraph (version B):
This survey is intended to help identify the most common interface
surfaces between security protocols and transport protocols, and
between security protocols and applications.
Paragraph (version B):
One of the goals of Transport Services 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, restrict the set of transport protocols that can be used to
those that offer a reliable stream of bytes.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
Security Feature: a feature that a network security layer provides
to applications.  Examples include authentication, encryption, key
generation, session resumption, and privacy.  Features may be
Mandatory or Optional for an application's implementation.
Security Features extend the set of Transport Features described
in RFC8095 and provided by Transport Services implementations.
Paragraph (version A):
Security Protocol: a defined network protocol that implements one
or more security features.  Security protocols may be used
alongside transport protocols, and in combination with other
security protocols when appropriate.
Paragraph (version B):
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.
Paragraph (version A):
Cryptographic context: a set of cryptographic parameters,
including but not necessarily limited to keys for encryption,
authentication, and session resumption, enabling authorized
parties to a session to communicate securely.
Paragraph (version A):
In this section, we enumerate Security Features exposed by protocols
discussed in the remainder of this document.  Protocol security (and
privacy) properties that are unrelated to the API surface exposed by
such protocols, such as client or server identity hiding, are not
listed here as features.
Paragraph (version A):
Forward-secure session key establishment: Establishing
cryptographic keys with forward-secure properties.
Paragraph (version A):
Cryptographic algorithm negotiation: Negotiating support of
protocol algorithms, including algorithms for encryption, hashing,
MAC (PRF), and digital signatures.
Paragraph (version A):
Session caching and management: Managing session state caches used
for subsequent connections, with the aim of amortizing connection
establishment costs.
Paragraph (version A):
Peer authentication: Authenticating peers using generic or
protocol-specific mechanisms, such as certificates, raw public
keys, pre-shared keys, or EAP methods.
Paragraph (version A):
Unilateral responder authentication: Requiring authentication for
the responder of a connection.
Paragraph (version A):
Mutual authentication: Establishing connections in which both
endpoints are authenticated.
Paragraph (version A):
Application authentication delegation: Delegating to applications
out-of-band to perform peer authentication.
Paragraph (version A):
Record (channel or datagram) confidentiality and integrity:
Encrypting and authenticating application plaintext bytes sent
between peers over a channel or in individual datagrams.
Paragraph (version A):
Partial record confidentiality: Encrypting some portion of
records.
Paragraph (version A):
Optional record integrity: Optionally authenticating certain
records.
Paragraph (version A):
Record replay prevention: Detecting and defending against record
replays, which can be due to in-network retransmissions.
Paragraph (version A):
Early data support: Transmitting application data prior to secure
connection establishment via a handshake.  For TLS, this support
begins with TLS 1.3.
Paragraph (version A):
Connection mobility: Allowing a connection to be multihomed or
resilient across network interface or address changes, such as NAT
rebindings that occur without an endpoint's knowledge.  Mobility
allows cryptographic key material and other state information to
be reused in the event of a connection change.
Paragraph (version A):
Application-layer feature negotiation: Securely negotiating
application-specific functionality.  Such features may be
necessary for further application processing, such as the TLS
parent connection protocol type via ALPN RFC7301 or desired
application identity via SNI RFC6066.
Paragraph (version A):
Configuration extensions: Adding protocol features via extensions
or configuration options.  TLS extensions are a primary example of
this feature.
Paragraph (version A):
Out-of-order record receipt: Processing of records received out-
of-order.
Paragraph (version A):
Source validation (cookie or puzzle based): Validating peers and
mitigating denial-of-service (DoS) attacks via explicit proof of
origin (cookies) or work mechanisms (puzzles).
Paragraph (version A):
Length-hiding padding: Adding padding to records in order to hide
plaintext message length and mitigate amplification attack
vectors.
Paragraph (version A):
This section contains descriptions of security protocols currently
used to protect data being sent over a network.
Paragraph (version A):
For each protocol, we describe its provided features and dependencies
on other protocols.
Paragraph (version B):
This section contains brief descriptions of the various security
protocols currently used to protect data being sent over a network.
The interfaces between these protocols and transports are described
in transport-interface; the interfaces between these protocols and
applications are described in application-interface.
Paragraph (version B):
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.
Paragraph (version A):
TLS is the composition of a handshake and record protocol RFC8446.
The record protocol is designed to marshal an arbitrary, in-order
stream of bytes from one endpoint to the other.  It handles
segmenting, compressing (when enabled), and encrypting data into
discrete records.  When configured to use an authenticated encryption
with associated data (AEAD) algorithm, it also handles nonce
generation and encoding for each record.  The record protocol is
hidden from the client behind a bytestream-oriented API.
Paragraph (version A):
The handshake protocol serves several purposes, including: peer
authentication, protocol option (key exchange algorithm and
ciphersuite) negotiation, and key derivation.  Peer authentication
may be mutual; however, commonly, only the server is authenticated.
X.509 certificates are commonly used in this authentication step,
though other mechanisms, such as raw public keys RFC7250, exist.  The
client is not authenticated unless explicitly requested by the
server.
Paragraph (version A):
The handshake protocol is also extensible.  It allows for a variety
of extensions to be included by either the client or server.  These
extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection
RFC7301, or signals to the server to aid operation, e.g., Server Name
Indication (SNI) RFC6066.  Various extensions also exist to tune the
parameters of the record protocol, e.g., the maximum fragment length
RFC6066 and record size limit RFC8449.
Paragraph (version A):
Alerts are used to convey errors and other atypical events to the
endpoints.  There are two classes of alerts: closure and error
alerts.  A closure alert is used to signal to the other peer that the
sender wishes to terminate the connection.  The sender typically
follows a close alert with a TCP FIN segment to close the connection.
Error alerts are used to indicate problems with the handshake or
individual records.  Most errors are fatal and are followed by
connection termination.  However, warning alerts may be handled at
the discretion of the implementation.
Paragraph (version A):
Stateful and stateless cross-connection session resumption.
Paragraph (version A):
Peer authentication (Certificate, raw public key, and pre-shared
key).
Paragraph (version A):
Record replay prevention.
Paragraph (version A):
Application-layer feature negotiation.
Paragraph (version A):
Configuration extensions.
Paragraph (version A):
Early data support (starting with TLS 1.3).
Paragraph (version A):
Optional record-layer padding (starting with TLS 1.3).
Paragraph (version A):
In-order, reliable bytestream transport.
Paragraph (version A):
DTLS is modified from TLS to operate with the possibility of packet
loss, reordering, and duplication that may occur when operating over
UDP.  To enable out-of-order delivery of application data, the DTLS
record protocol itself has no inter-record dependencies.  However, as
the handshake requires reliability, each handshake message is
assigned an explicit sequence number to enable retransmissions of
lost packets and in-order processing by the receiver.  Handshake
message loss is remedied by sender retransmission after a
configurable period in which the expected response has not yet been
received.
Paragraph (version A):
As the DTLS handshake protocol runs atop the record protocol, to
account for long handshake messages that cannot fit within a single
record, DTLS supports fragmentation and subsequent reconstruction of
handshake messages across records.  The receiver must reassemble
records before processing.
Paragraph (version A):
Since datagrams can be replayed, DTLS provides optional anti-replay
detection based on a window of acceptable sequence numbers RFC6347.
Paragraph (version A):
See also the features from TLS.
Paragraph (version A):
DTLS relies on an unreliable datagram transport.
Paragraph (version A):
Uniqueness of the session within the transport flow (only one DTLS
connection on a UDP 4-tuple, for example); or else support for the
connection identifier extension to enable demultiplexing.
Paragraph (version A):
Path MTU discovery.
Paragraph (version A):
For the handshake: Reliable, in-order transport.  DTLS provides
its own reliability.
Paragraph (version B):
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.
Paragraph (version B):
ZRTP RFC6189 is an alternative key agreement protocol for SRTP.  It
uses standard SRTP to protect RTP data packets and RTCP packets, but
provides alternative key agreement and identity management protocols.
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.
Paragraph (version B):
The following security protocols provide protection for both
application payloads and headers that are used for transport
services.
Paragraph (version A):
Starting the handshake to generate keys and provide authentication
(and providing the transport for the handshake).
Paragraph (version A):
Client address validation.
Paragraph (version A):
Key ready events from TLS to notify the QUIC transport.
Paragraph (version A):
Exporting secrets from TLS to the QUIC transport.
Paragraph (version A):
The QUIC transport layer support multiple streams over a single
connection.  QUIC implements a record protocol for TLS handshake
messages to establish a connection.  These messages are sent in
CRYPTO frames I-D.ietf-quic-transport in Initial and Handshake
packets.  Initial packets are encrypted using fixed keys derived from
the QUIC version and public packet information (Connection ID).
Handshake packets are encrypted using TLS handshake secrets.  Once
TLS completes, QUIC uses the resulting traffic secrets to for the
QUIC connection to protect the rest of the frames.  QUIC supports
0-RTT data using previously negotiated connection secrets Early data
is sent in 0-RTT packets, which may be included in the same datagram
as the Initial and Handshake packets.
Paragraph (version A):
QUIC transport assumes an unreliable transport, e.g., UDP.
Paragraph (version A):
QUIC transport relies on TLS 1.3 for key exchange, peer
authentication, and shared secret derivation.
Paragraph (version A):
For the handshake: Reliable, in-order transport.  QUIC provides
its own reliability.
Paragraph (version A):
IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and
TCP port 4500.  Its primary goal is to generate keys for Security
Associations (SAs).  An SA contains shared (cryptographic)
information used for establishing other SAs or keying ESP; See ESP.
IKEv2 first uses a Diffie-Hellman key exchange to generate keys for
the "IKE SA", which is a set of keys used to encrypt further IKEv2
messages.  IKE then performs a phase of authentication in which both
peers present blobs signed by a shared secret or private key that
authenticates the entire IKE exchange and the IKE identities.  IKE
then derives further sets of keys on demand, which together with
traffic policies are referred to as the "Child SA".  These Child SA
keys are used by ESP.
Paragraph (version A):
IKEv2 negotiates which protocols are acceptable to each peer for both
the IKE and Child SAs using "Proposals".  Each proposal specifies an
encryption and authentication algorithm, or an AEAD algorithm, a
Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
algorithm.  Each peer may support multiple proposals, and the most
preferred mutually supported proposal is chosen during the handshake.
Paragraph (version A):
The authentication phase of IKEv2 may use Shared Secrets,
Certificates, Digital Signatures, or an EAP (Extensible
Authentication Protocol) method.  At a minimum, IKEv2 takes two round
trips to set up both an IKE SA and a Child SA.  If EAP is used, this
exchange may be expanded.
Paragraph (version A):
Any SA used by IKEv2 can be re-keyed before expiration, which is
usually based either on time or number of bytes encrypted.
Paragraph (version A):
There is an extension to IKEv2 that allows session resumption
RFC5723.
Paragraph (version A):
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
set of Security Associations to migrate over different outer IP
addresses and interfaces RFC4555.
Paragraph (version A):
When UDP is not available or well-supported on a network, IKEv2 may
be encapsulated in TCP RFC8229.
Paragraph (version A):
ESP is a protocol that encrypts and authenticates IPv4 and IPv6
packets.  The keys used for both encryption and authentication can be
derived from an IKEv2 exchange.  ESP Security Associations come as
pairs, one for each direction between two peers.  Each SA is
identified by a Security Parameter Index (SPI), which is marked on
each encrypted ESP packet.
Paragraph (version A):
ESP packets include the SPI, a sequence number, an optional
Initialization Vector (IV), payload data, padding, a length and next
header field, and an Integrity Check Value.
Paragraph (version A):
Since ESP operates on IP packets, it is not directly tied to the
transport protocols it encrypts.  This means it requires little or no
change from transports in order to provide security.
Paragraph (version A):
ESP packets may be sent directly over IP, but where network
conditions warrant (e.g., when a NAT is present or when a firewall
blocks such packets) they may be encapsulated in UDP RFC3948 or TCP
RFC8229.
Paragraph (version A):
Peer authentication (certificate, raw public key, pre-shared key,
and EAP).
Paragraph (version A):
Session resumption.
Paragraph (version A):
Record confidentiality and integrity.
Paragraph (version A):
Availability of UDP to negotiate, or implementation support for
TCP-encapsulation.
Paragraph (version A):
Some EAP authentication types require accessing a hardware device,
such as a SIM card; or interacting with a user, such as password
prompting.
Paragraph (version A):
Since ESP is below transport protocols, it does not have any
dependencies on the transports themselves, other than on UDP or
TCP where encapsulation is employed.
Paragraph (version A):
SRTP adds confidentiality and optional integrity protection to RTP
data packets, and adds confidentially and mandatory integrity
protection to RTCP packets.  For RTP data packets, this is done by
encrypting the payload section of the packet and optionally appending
an authentication tag (MAC) as a packet trailer, with the RTP header
authenticated but not encrypted (the RTP header was left unencrypted
to enable RTP header compression RFC2508 RFC3545).  For RTCP packets,
the first packet in the compound RTCP packet is partially encrypted,
leaving the first eight octets of the header as clear-text to allow
identification of the packet as RTCP, while the remainder of the
compound packet is fully encrypted.  The entire RTCP packet is then
authenticated by appending a MAC as packet trailer.
Paragraph (version A):
Packets are encrypted using session keys, which are ultimately
derived from a master key and an additional master salt and session
salt.  SRTP packets carry a 2-byte sequence number to partially
identify the unique packet index.  SRTP peers maintain a separate
roll-over counter (ROC) for RTP data packets that is incremented
whenever the sequence number wraps.  The sequence number and ROC
together determine the packet index.  RTCP packets have a similar,
yet differently named, field called the RTCP index which serves the
same purpose.
Paragraph (version A):
Numerous encryption modes are supported.  For popular modes of
operation, e.g., AES-CTR, the (unique) initialization vector (IV)
used for each encryption mode is a function of the RTP SSRC
(synchronization source), packet index, and session "salting key".
Paragraph (version A):
SRTP offers replay detection by keeping a replay list of already seen
and processed packet indices.  If a packet arrives with an index that
matches one in the replay list, it is silently discarded.
Paragraph (version A):
DTLS RFC5764 is commonly used to perform mutual authentication and
key agreement for SRTP RFC5763.  Peers use DTLS to perform mutual
certificate-based authentication on the media path, and to generate
the SRTP master key.  Peer certificates can be issued and signed by a
certificate authority.  Alternatively, certificates used in the DTLS
exchange can be self-signed.  If they are self-signed, certificate
fingerprints are included in the signaling exchange (e.g., in SIP or
WebRTC), and used to bind the DTLS key exchange in the media plane to
the signaling plane.  The combination of a mutually authenticated
DTLS key exchange on the media path and a fingerprint sent in the
signaling channel protects against active attacks on the media,
provided the signaling can be trusted.  Signaling needs to be
protected as described in, for example, SIP RFC3261 Authenticated
Identity Management RFC8224 or the WebRTC security architecture I-
D.ietf-rtcweb-security-arch, to provide complete system security.
Paragraph (version A):
Optional authentication of data packets.
Paragraph (version A):
Mandatory authentication of control packets.
Paragraph (version A):
Secure RTP can run over UDP or TCP.
Paragraph (version A):
External key derivation and management protocol, e.g., DTLS
RFC5763.
Paragraph (version A):
External identity management protocol, e.g., SIP Authenticated
Identity Management RFC8224, WebRTC Security Architecture I-
D.ietf-rtcweb-security-arch.
Paragraph (version A):
ZRTP RFC6189 is an alternative key agreement protocol for SRTP.  It
uses standard SRTP to protect RTP data packets and RTCP packets, but
provides alternative key agreement and identity management protocols.
Paragraph (version A):
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.
Paragraph (version A):
ZRTP does not rely on a PKI or external identity management system.
Rather, it uses an ephemeral Diffie-Hellman key exchange with hash
commitment to allow detection of man-in-the-middle attacks.  This
requires endpoints to display a short authentication string that the
users must read and verbally compare to validate the hashes and
ensure security.  Endpoints cache some key material after the first
call to use in subsequent calls; this is mixed in with the Diffie-
Hellman shared secret, so the short authentication string need only
be checked once for a given user.  This gives key continuity
properties analogous to the secure shell (ssh) RFC4253.
Paragraph (version A):
Tcpcrypt extends TCP to enable opportunistic encryption between the
two ends of a TCP connection RFC8548.  It is a family of TCP
encryption protocols (TEP), distinguished by key exchange algorithm.
The use of a TEP is negotiated with a TCP option during the initial
TCP handshake via the mechanism described by TCP Encryption
Negotiation Option (ENO) RFC8547.  In the case of initial session
establishment, once a tcpcrypt TEP has been negotiated the key
exchange occurs within the data segments of the first few packets
exchanged after the handshake completes.  The initiator of a
connection sends a list of supported AEAD algorithms, a random nonce,
and an ephemeral public key share.  The responder typically chooses a
mutually-supported AEAD algorithm and replies with this choice, its
own nonce, and ephemeral key share.  An initial shared secret is
derived from the ENO handshake, the tcpcrypt handshake, and the
initial keying material resulting from the key exchange.  The traffic
encryption keys on the initial connection are derived from the shared
secret.  Connections can be re-keyed before the natural AEAD limit
for a single set of traffic encryption keys is reached.
Paragraph (version A):
Each tcpcrypt session is associated with a ladder of resumption IDs,
each derived from the respective entry in a ladder of shared secrets.
These resumption IDs can be used to negotiate a stateful resumption
of the session in a subsequent connection, resulting in use of a new
shared secret and traffic encryption keys without requiring a new key
exchange.  Willingness to resume a session is signaled via the ENO
option during the TCP handshake.  Given the length constraints
imposed by TCP options, unlike stateless resumption mechanisms (such
as that provided by session tickets in TLS) resumption in tcpcrypt
requires the maintenance of state on the server, and so successful
resumption across a pool of servers implies shared state.
Paragraph (version A):
Owing to middlebox ossification issues, tcpcrypt only protects the
payload portion of a TCP packet.  It does not encrypt any header
information, such as the TCP sequence number.
Paragraph (version A):
Stateful cross-connection session resumption.
Paragraph (version A):
TCP for in-order, reliable transport.
Paragraph (version A):
TCP Encryption Negotiation Option (ENO).
Paragraph (version A):
WireGuard is a layer 3 protocol designed as an alternative to IPsec
WireGuard for certain use cases.  It uses UDP to encapsulate IP
datagrams between peers.  Unlike most transport security protocols,
which rely on 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.
Paragraph (version B):
CurveCP CurveCP is a UDP-based transport security protocol from
Daniel J.  Bernstein.  Unlike other security protocols, it is based
entirely upon highly efficient public key algorithms.  This removes
many pitfalls associated with nonce reuse and key synchronization.
CurveCP provides its own reliability for application data as part of
its protocol.
Paragraph (version B):
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.
Paragraph (version B):
WireGuard is an IP-layer protocol designed as an alternative to IPsec
WireGuard for certain use cases.  It uses UDP to encapsulate IP
datagrams between peers.  Unlike most transport security protocols,
which rely on 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.
Paragraph (version A):
WireGuard is a simple VPN protocol that binds a pre-shared public key
to one or more IP addresses.  Users configure WireGuard by
associating peer public keys with IP addresses.  These mappings are
stored in a CryptoKey Routing Table.  (See Section 2 of WireGuard for
more details and sample configurations.)  These keys are used upon
WireGuard packet transmission and reception.  For example, upon
receipt of a Handshake Initiation message, receivers use the static
public key in their CryptoKey routing table to perform necessary
cryptographic computations.
Paragraph (version A):
x25519 Curve25519 and HKDF RFC5869 for ECDH and key derivation.
Paragraph (version A):
ChaCha20+Poly1305 RFC8439 for packet authenticated encryption.
Paragraph (version A):
BLAKE2s BLAKE2 for hashing.
Paragraph (version A):
There is no cryptographic agility.  If weaknesses are found in any of
these algorithms, new message types using new algorithms must be
introduced.
Paragraph (version A):
If a WireGuard receiver is under heavy load and cannot process a
packet, e.g., cannot spare CPU cycles for expensive public key
cryptographic operations, it can reply with a cookie similar to DTLS
and IKEv2.  This cookie only proves IP address ownership.  Any rate
limiting scheme can be applied to packets coming from non-spoofed
addresses.
Paragraph (version A):
Peer authentication (public-key and PSK).
Paragraph (version A):
Record replay prevention (Stateful, timestamp-based).
Paragraph (version A):
Datagram transport.
Paragraph (version A):
Out-of-band key distribution and management.
Paragraph (version A):
CurveCP CurveCP is a UDP-based transport security protocol from
Daniel J.  Bernstein.  Unlike other transport security protocols, it
is based entirely upon highly efficient public key algorithms.  This
removes many pitfalls associated with nonce reuse and key
synchronization.
Paragraph (version A):
CurveCP is a UDP-based transport security protocol.  It is built on
three principal features: exclusive use of public key authenticated
encryption of packets, server-chosen cookies to prohibit memory and
computation DoS at the server, and connection mobility with a client-
chosen ephemeral identifier.
Paragraph (version A):
There are two rounds in CurveCP.  In the first round, the client
sends its first initialization packet to the server, carrying its
(possibly fresh) ephemeral public key C', with zero-padding encrypted
under the server's long-term public key.  The server replies with a
cookie and its own ephemeral key S' and a cookie that is to be used
by the client.  Upon receipt, the client then generates its second
initialization packet carrying: the ephemeral key C', cookie, and an
encryption of C', the server's domain name, and, optionally, some
message data.  The server verifies the cookie and the encrypted
payload and, if valid, proceeds to send data in return.  At this
point, the connection is established and the two parties can
communicate.
Paragraph (version A):
The use of public-key encryption and authentication, or "boxing",
simplifies problems that come with symmetric key management and nonce
synchronization.  For example, it allows the sender of a message to
be in complete control of each message's nonce.  It does not require
either end to share secret keying material.  Furthermore, it allows
connections (or sessions) to be associated with unique ephemeral
public keys as a mechanism for enabling forward secrecy given the
risk of long-term private key compromise.
Paragraph (version A):
The client and server do not perform a standard key exchange.
Instead, in the initial exchange of packets, each party provides its
own ephemeral key to the other end.  The client can choose a new
ephemeral key for every new connection.  However, the server must
rotate these keys on a slower basis.  Otherwise, it would be trivial
for an attacker to force the server to create and store ephemeral
keys with a fake client initialization packet.
Paragraph (version A):
Servers use cookies for source validation.  After receiving a
client's initial packet, encrypted under the server's long-term
public key, a server generates and returns a stateless cookie that
must be echoed back in the client's following message.  This cookie
is encrypted under the client's ephemeral public key.  This stateless
technique prevents attackers from hijacking client initialization
packets to obtain cookie values to flood clients.  (A client would
detect the duplicate cookies and reject the flooded packets.)
Similarly, replaying the client's second packet, carrying the cookie,
will be detected by the server.
Paragraph (version A):
CurveCP supports client authentication by allowing clients to send
their long-term public keys in the second initialization packet.  A
server can verify this public key and, if untrusted, drop the
connection and subsequent data.
Paragraph (version A):
Unlike some other protocols, CurveCP data packets leave only the
ephemeral public key, connection ID, and per-message nonce in the
clear.  All other data is encrypted.
Paragraph (version A):
Datagram confidentiality and integrity (via public key
encryption).
Paragraph (version A):
Connection mobility (based on a client-chosen ephemeral
identifier).
Paragraph (version A):
Optional length-hiding and anti-amplification padding.
Paragraph (version A):
MinimalT is a secure transport protocol built on top of a widespread
directory service.  Clients and servers interact with local directory
services to (a) resolve server information and (b) publish ephemeral
state information, respectively.  Clients connect to a local resolver
once at boot time.  Through this resolver they recover the IP
address(es) and public key(s) of each server to which they want to
connect.
Paragraph (version A):
Connections are instances of user-authenticated, mobile sessions
between two endpoints.  Connections run within tunnels between hosts.
A tunnel is a server-authenticated container that multiplexes
multiple connections between the same hosts.  All connections in a
tunnel share the same transport state machine and encryption.  Each
tunnel has a dedicated control connection used to configure and
manage the tunnel over time.  Moreover, since tunnels are independent
of the network address information, they may be reused as both ends
of the tunnel move about the network.  This does however imply that
connection establishment and packet encryption mechanisms are
coupled.
Paragraph (version A):
Before a client connects to a remote service, it must first establish
a tunnel to the host providing or offering the service.  Tunnels are
established in 1-RTT using an ephemeral key obtained from the
directory service.  Tunnel initiators provide their own ephemeral key
and, optionally, a DoS puzzle solution such that the recipient
(server) can verify the authenticity of the request and derive a
shared secret.  Within a tunnel, new connections to services may be
established.
Paragraph (version A):
Additional (orthogonal) transport features include: connection
multiplexing between hosts across shared tunnels, and congestion
control state is shared across connections between the same host
pairs.
Paragraph (version A):
DoS mitigation (puzzle-based).
Paragraph (version A):
Out-of-order receipt record.
Paragraph (version A):
Connection mobility (based on tunnel identifiers).
Paragraph (version A):
A DNS-like resolution service to obtain location information (an
IP address) and ephemeral keys.
Paragraph (version A):
A PKI trust store for certificate validation.
Paragraph (version A):
OpenVPN facilitates authentication using either a pre-shared static
key or using X.509 certificates and TLS.  In pre-shared key mode,
OpenVPN derives keys for encryption and authentication directly from
one or multiple symmetric keys.  In TLS mode, OpenVPN encapsulates a
TLS handshake, in which both peers must present a certificate for
authentication.  After the handshake, both sides contribute random
source material to derive keys for encryption and authentication
using the TLS pseudo random function (PRF).  OpenVPN provides the
possibility to authenticate and encrypt the TLS handshake itself
using a pre-shared key or passphrase.  Furthermore, it supports re-
keying using TLS.
Paragraph (version A):
After authentication and key exchange, OpenVPN encrypts payload data,
i.e., IP packets or Ethernet frames, and authenticates the payload
using HMAC.  Applications can select an arbitrary encryption
algorithm (cipher) and key size, as well hash function for HMAC.  The
default cipher and hash functions are AES-GCM and SHA1, respectively.
Recent versions of the protocol support cipher negotiation.
Paragraph (version A):
OpenVPN can run over TCP or UDP.  When running over UDP, OpenVPN
provides a simple reliability layer for control packets such as the
TLS handshake and key exchange.  It assigns sequence numbers to
packets, acknowledges packets it receives, and retransmits packets it
deems lost.  Similar to DTLS, this reliability layer is not used for
data packets, which prevents the problem of two reliability
mechanisms being encapsulated within each other.  When running over
TCP, OpenVPN includes the packet length in the header, which allows
the peer to deframe the TCP stream into messages.
Paragraph (version A):
For replay protection, OpenVPN assigns an identifier to each outgoing
packet, which is unique for the packet and the currently used key.
In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN
combines a timestamp with an incrementing sequence number into a
64-bit identifier.  In TLS mode with CBC cipher mode, OpenVPN omits
the timestamp, so identifiers are only 32-bit.  This is sufficient
since OpenVPN can guarantee the uniqueness of this identifier for
each key, as it can trigger re-keying if needed.
Paragraph (version A):
OpenVPN supports connection mobility by allowing a peer to change its
IP address during an ongoing session.  When configured accordingly, a
host will accept authenticated packets for a session from any IP
address.
Paragraph (version A):
Peer authentication using certificates or pre-shared key.
Paragraph (version A):
Mandatory mutual authentication.
Paragraph (version A):
Length-hiding padding.
Paragraph (version A):
For control packets such as handshake and key exchange: Reliable,
in-order transport.  Reliability is provided either by TCP, or by
OpenVPN's own reliability layer when using UDP.
Paragraph (version A):
There exists a common set of features shared across the transport
protocols surveyed in this document.  Mandatory features constitute a
baseline of functionality that an application may assume for any
Transport Services implementation.  They were selected on the basis
that they are either (a) required for any secure transport protocol
or (b) nearly ubiquitous amongst common secure transport protocols.
Paragraph (version A):
Optional features by contrast may vary from implementation to
implementation, and so an application cannot simply assume they are
available.  Applications learn of and use optional features by
querying for their presence and support.  Optional features may not
be implemented, or may be disabled if their presence impacts
transport services or if a necessary transport service or application
dependency is unavailable.
Paragraph (version A):
In this context, an application dependency is an aspect of the
security feature which can be exposed to the application.  An
application dependency may be required for the security feature to
function, or it may provide additional information and control to the
application.  For example, an application may need to provide
information such as keying material or authentication credentials, or
it may want to restrict which cryptographic algorithms to allow for
negotiation.
Paragraph (version A):
Mandatory features must be supported regardless of transport and
application services available.  Note that not all mandatory features
are provided by each surveyed protocol above.  For example, tcpcrypt
does not provide responder authentication and CurveCP does not
provide forward-secure session key establishment.
Paragraph (version A):
In this section we list optional features along with their necessary
application dependencies, if any.
Paragraph (version A):
Application dependency: Application provisioning and
distribution of pre-shared keys.
Paragraph (version A):
Application dependency: Mutual authentication credentials
required.
Paragraph (version A):
Application dependency: Application awareness of supported or
desired algorithms.
Paragraph (version A):
Application dependency: Application opt-in and policy for
endpoint authentication.
Paragraph (version A):
Application dependency: Specification of application-layer
features or functionality.
Paragraph (version A):
Application dependency: Specification of application-specific
extensions.
Paragraph (version A):
Length-hiding padding (LHP): (Optional) Application dependency:
Knowledge of desired padding policies.  Some protocols, such as
IKE, can negotiate application-agnostic padding policies.
Paragraph (version A):
Application dependency: Anti-replay protections or hints of
data idempotency.
Paragraph (version A):
The following table lists the availability of the above-listed
optional features in each of the analyzed protocols.  "Mandatory"
indicates that the feature is intrinsic to the protocol and cannot be
disabled.  "Supported" indicates that the feature is optionally
provided natively or through a (standardized, where applicable)
extension.
Paragraph (version A):
Pre-Shared Key Import Either the handshake protocol or the
application directly can supply pre-shared keys for the record
protocol use for encryption/decryption and authentication.  If the
application can supply keys directly, this is considered explicit
import; if the handshake protocol traditionally provides the keys
directly, it is considered direct import; if the keys can only be
shared by the handshake, they are considered non-importable.
Paragraph (version A):
Pre-Shared Key Export The handshake protocol will generate one or
more keys to be used for record encryption/decryption and
authentication.  These may be explicitly exportable to the
application, traditionally limited to direct export to the record
protocol, or inherently non-exportable because the keys must be
used directly in conjunction with the record protocol.
Paragraph (version B):
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.
Paragraph (version B):
The following protocols all depend upon running on a transport
protocol that provides a reliable, in-order stream of bytes.  This is
typically TCP.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
One protocol surveyed, tcpcrypt, has an direct dependency on a
feature in the transport that is needed for its functionality.
Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP
Encryption Negotiation Option (ENO) I-D.ietf-tcpinc-tcpeno to
negotiate its protocol support.
Paragraph (version B):
QUIC, CurveCP, and MinimalT provide both transport functionality and
security functionality.  They have a dependencies 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.
Paragraph (version B):
Identities and Private Keys: The application can provide its
identities (certificates) and private keys, or mechanisms to
access these, to the security protocol to use during handshakes.
Paragraph (version B):
Supported Algorithms (Key Exchange, Signatures, and Ciphersuites):
The application can choose the algorithms that are supported for
key exchange, signatures, and ciphersuites.
Paragraph (version B):
Extensions (Application-Layer Protocol Negotiation): The
application enables or configures extensions that are to be
negotiated by the security protocol, such as ALPN RFC7301.
Paragraph (version B):
Session Cache Management: 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.
Paragraph (version B):
Authentication Delegation: The application provides access to a
separate module that will provide authentication, using EAP for
example.
Paragraph (version B):
Pre-Shared Key Import: Either the handshake protocol or the
application directly can supply pre-shared keys for the record
protocol use for encryption/decryption and authentication.  If the
application can supply keys directly, this is considered explicit
import; if the handshake protocol traditionally provides the keys
directly, it is considered direct import; if the keys can only be
shared by the handshake, they are considered non-importable.
Paragraph (version B):
Identity Validation: During a handshake, the security protocol
will conduct identity validation of the peer.  This can call into
the application to offload validation.
Paragraph (version B):
Connection Termination: The security protocol may be instructed to
tear down its connection and session information.  This is needed
by some protocols to prevent application data truncation attacks.
Paragraph (version B):
Key Update: 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.
Paragraph (version B):
Pre-Shared Key Export: The handshake protocol will generate one or
more keys to be used for record encryption/decryption and
authentication.  These may be explicitly exportable to the
application, traditionally limited to direct export to the record
protocol, or inherently non-exportable because the keys must be
used directly in conjunction with the record protocol.
Paragraph (version B):
Key Expiration: 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.
Paragraph (version B):
Mobility Events: 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).