Draft: draft-ietf-taps-transport-security

Commentary: can you please take a look ? 
 Approved with IKE nitsNo objections on my part .
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 RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
WireGuard.  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 TAPS system may need to support.
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 RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP,
MinimalT.  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 TAPS system may need to support.
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 RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
WireGuard.  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.
Finally, we distill the application and transport interfaces provided
by the transport security protocols.
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 RFC8095 by
describing the interfaces required to add security protocols.  It
examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (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.
Finally, we distill the application and transport interfaces provided
by the transport security protocols.
Paragraph (version A):
Forward-secure key establishment: Cryptographic key establishment
with forward secure properties.
Paragraph (version B):
Forward-secure session key establishment: Cryptographic key
establishment with forward secure properties.
Paragraph (version A):
Application-layer authentication delegation: Out-of-band peer
authentication performed by applications outside of the connection
establishment.
Paragraph (version B):
Unilateral responder authentication: Required authentication for
the responder of a connection.
Paragraph (version B):
Application authentication delegation: Out-of-band peer
authentication performed by applications outside of the connection
establishment.
Paragraph (version A):
Mandatory server authentication, optional client authentication.
Paragraph (version A):
IKEv2 is a control protocol that runs on UDP port 500.  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.  It then goes through a
phase of authentication in which both peers present blobs signed by a
shared secret or private key, after which another set of keys is
derived, 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 may contain
an encryption algorithm, an authentication 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 B):
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 B):
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):
Any SA used by IKEv2 can be rekeyed upon expiration, which is usually
based either on time or number of bytes encrypted.
Paragraph (version A):
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
set of Security Associations to migrate over different addresses and
interfaces RFC4555.
Paragraph (version B):
Any SA used by IKEv2 can be rekeyed before expiration, which is
usually based either on time or number of bytes encrypted.
Paragraph (version B):
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):
Tcpcrypt is a lightweight extension to the TCP protocol to enable
opportunistic encryption with hooks available to the application
layer for implementation of endpoint authentication.
Paragraph (version B):
Tcpcrypt 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.
Paragraph (version A):
Tcpcrypt exposes a universally-unique connection-specific session ID
to the application, suitable for application-level endpoint
authentication either in-band or out-of-band.
Paragraph (version A):
WireGuard is a layer 3 protocol designed to complement or replace
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):
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 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) public 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):
The use of public-key encryption and authentication, or "boxing", is
done to simplify problems that come with symmetric key management and
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 B):
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):
CurveCP supports a weak form of client authentication.  Clients are
permitted 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, the connection ID, and the per-message nonce in
the clear.  Everything else is encrypted.
Paragraph (version B):
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 B):
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 B):
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 B):
Out-of-order receipt record.
Paragraph (version A):
Mandatory features must be supported regardless of transport and
application services available.
Paragraph (version A):
Public-key certificate based authentication.
Paragraph (version A):
Application dependency: Application providing trust
information.  Note that most systems provide default trust
stores used to authenticate peers based on certificates.  In
such systems, applications need not provide any trust
information.
Paragraph (version A):
Application dependency: Application providing trust
information, see above.
Paragraph (version B):
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 B):
Application dependency: Mutual authentication credentials
required.
Paragraph (version A):
Application dependency: Mutual authentication credentials
required for application support.
Paragraph (version A):
Application dependency: Knowledge of desired padding policies.
Paragraph (version B):
Length-hiding padding (LHP): (Optional) Application dependency:
Knowledge of desired padding policies.  Some protocols, such as
IKE, can negotiate application-agnostic padding policies.