TLS within QUIC relies on a reliable stream abstraction for its handshake. <del> 3.4. </del>  <del> gQUIC is a UDP-based multiplexed streaming protocol designed and deployed by Google following experience from deploying SPDY, the proprietary predecessor to HTTP/2.  gQUIC was originally known as "QUIC": this document uses gQUIC to unambiguously distinguish it from the standards-track IETF QUIC.  The proprietary technical forebear of IETF QUIC, gQUIC was originally designed with tightly-integrated security and application data transport protocols. </del>  <del> 3.4.1. </del>  ((TODO: write me)) <del> 3.4.2. </del>  ((TODO: write me)) <del> 3.5. MinimalT is a UDP-based transport security protocol designed to offer confidentiality, mutual authentication, DoS prevention, and connection mobility MinimalT.  One major goal of the protocol is to leverage existing protocols to obtain server-side configuration information used to more quickly bootstrap a connection.  MinimalT uses a variant of TCP's congestion control algorithm. 3.5.1. 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. 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 the connection establishment and packet encryption mechanisms are coupled. 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. 3.5.2. 0-RTT forward secrecy for new connections. DoS prevention by client-side puzzles. Tunnel-based mobility. (Transport Feature) Connection multiplexing between hosts across shared tunnels. (Transport Feature) Congestion control state is shared across connections between the same host pairs. 3.5.3. A DNS-like resolution service to obtain location information (an IP address) and ephemeral keys. A PKI trust store for certificate validation. 3.6. 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. 3.6.1. 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. 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. The use of only 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. 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. Unlike TCP, the server employs cookies to enable source validation. After receiving the client's initial packet, encrypted under the server's long-term public key, the 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. 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. 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. 3.6.2. Forward-secure data encryption and authentication. Per-packet public-key encryption. 1-RTT session bootstrapping. Connection mobility based on a client-chosen ephemeral identifier. Connection establishment message padding to prevent traffic amplification. Sender-chosen explicit nonces, e.g., based on a sequence number. 3.6.3. An unreliable transport protocol such as UDP. 3.7. 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. 3.7.1. Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  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) I-D.ietf-tcpinc-tcpeno.  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. 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. 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. 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. 3.7.2. Forward-secure TCP payload encryption and integrity protection. Session caching and address-agnostic resumption. Connection re-keying. Application-level authentication primitive. 3.7.3. TCP TCP Encryption Negotiation Option (ENO) 3.8. </del>  IKEv2 RFC7296 and ESP RFC4303 together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either as for (ESP).  Each protocol can be used independently, but this document considers them together, since that is the most common pattern. <del> 3.8.1. </del>  <del> 3.8.1.1. </del>  IKEv2 is a control protocol that runs on UDP port 500.  Its primary goal is to generate keys for Security Associations (SAs).  It first When UDP is not available or well-supported on a network, IKEv2 may be encapsulated in TCP RFC8229. <del> 3.8.1.2. </del>  ESP is a protocol that encrypts and authenticates IPv4 and IPv6 packets.  The keys used for both encryption and authentication can be blocks such packets) they may be encapsulated in UDP RFC3948 or TCP RFC8229. <del> 3.8.2. </del>  <del> 3.8.2.1. </del>  Encryption and authentication of handshake packets. Peer authentication extensibility based on shared secret, certificates, digital signatures, or EAP methods. <del> 3.8.2.2. </del>  Data confidentiality and authentication. Limited flow confidentiality. <del> 3.8.3. </del>  <del> 3.8.3.1. </del>  Availability of UDP to negotiate, or implementation support for TCP-encapsulation. such as a SIM card; or interacting with a user, such as password prompting. <del> 3.8.3.2. </del>  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. <del> 3.9. </del>  <del> WireGuard is a layer 3 protocol designed to complement or replace IPsec WireGuard.  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. </del>  <del> 3.9.1. </del>  <del> 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. </del>  WireGuard builds on Noise Noise for 1-RTT key exchange with identity hiding.  The handshake hides peer identities as per the SIGMA This cookie only proves IP address ownership.  Any rate limiting scheme can be applied to packets coming from non-spoofed addresses. <del> 3.9.2. </del>  Optional PSK-based session creation. Cookie-based DoS mitigation similar to DTLS and IKEv2. <del> 3.9.3. </del>  Datagram transport. Out-of-band key distribution and management.  3.10. <del> SRTP - Secure RTP - is a profile for RTP that provides confidentiality, message authentication, and replay protection for data and control packets RFC3711.  SRTP packets are encrypted using a session key, which is derived from a separate master key.  Master keys are derived and managed externally, e.g., via DTLS, as specified in RFC 5763 RFC5763, under the control of a signaling protocol such as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch. </del>  3.10.1. <del> SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity protection to RTP control (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 itself is left unencrypted to enable RTP header compression RFC3545. For RTCP packets, the first packet in the compound RTCP packet is partially encrypted, leaving the first eight octets of the header as cleartext 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. </del>  <del> Packets are encrypted using session keys, which are ultimately derived from a master key and some 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 rollover 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. </del>  <del> 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". </del>  <del> 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. </del>  <del> DTLS RFC5764 is commonly used as a way to perform mutual authentication and key agreement for SRTP RFC5763.  (Here, certificates marshal public keys between endpoints.  Thus, self- signed certificates may be used if peers do not mutually trust one another, as is common on the Internet.)  When DTLS is used, certificate fingerprints are transmitted out-of-band using SIP. Peers typically verify that DTLS-offered certificates match that which are offered over SIP.  This prevents active attacks on RTP, but not on the signaling (SIP or WebRTC) channel. </del>  3.10.2. <del> Optional replay protection with tunable replay windows. </del>  <del> Out-of-order packet receipt. </del>  <del> (RFC5763) Mandatory mutually authenticated key exchange. </del>  <del> Partial encryption, protecting media payloads and control packets but not data packet headers. </del>  <del> Optional authentication of data packets; mandatory authentication of control packets. </del>  <del> 3.10.3. </del>  <del> External key derivation and management mechanism or protocol, e.g., DTLS RFC5763. </del>  <del> External signaling protocol to manage RTP parameters and locate and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb- security-arch. </del>  4.

Sort the protocols we describe based on perceived importance, popularity, etc. Basically, put non-standard ones at the end, and all else towards the front.
Correct!
I'm assuming the content itself hasn't changed, just moved around? It's not obvious from the diff, so LMK if not and I'll un-approve.

TLS within QUIC relies on a reliable stream abstraction for its handshake.  <ins> 3.3.4. </ins>  <ins> Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol designed and deployed by Google following experience from deploying SPDY, the proprietary predecessor to HTTP/2.  gQUIC was originally known as "QUIC": this document uses gQUIC to unambiguously distinguish it from the standards-track IETF QUIC.  The proprietary technical forebear of IETF QUIC, gQUIC was originally designed with tightly-integrated security and application data transport protocols. </ins>  <ins> 3.3.5. </ins> ((TODO: write me))  <ins> 3.3.6. </ins> ((TODO: write me))  <ins> 3.4. </ins> IKEv2 RFC7296 and ESP RFC4303 together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either as for (ESP).  Each protocol can be used independently, but this document considers them together, since that is the most common pattern.  <ins> 3.4.1. </ins>  <ins> 3.4.1.1. </ins> IKEv2 is a control protocol that runs on UDP port 500.  Its primary goal is to generate keys for Security Associations (SAs).  It first When UDP is not available or well-supported on a network, IKEv2 may be encapsulated in TCP RFC8229.  <ins> 3.4.1.2. </ins> ESP is a protocol that encrypts and authenticates IPv4 and IPv6 packets.  The keys used for both encryption and authentication can be blocks such packets) they may be encapsulated in UDP RFC3948 or TCP RFC8229.  <ins> 3.4.2. </ins>  <ins> 3.4.2.1. </ins> Encryption and authentication of handshake packets. Peer authentication extensibility based on shared secret, certificates, digital signatures, or EAP methods.  <ins> 3.4.2.2. </ins> Data confidentiality and authentication. Limited flow confidentiality.  <ins> 3.4.3. </ins>  <ins> 3.4.3.1. </ins> Availability of UDP to negotiate, or implementation support for TCP-encapsulation. such as a SIM card; or interacting with a user, such as password prompting.  <ins> 3.4.3.2. </ins> 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.  <ins> 3.5. </ins>  <ins> SRTP - Secure RTP - is a profile for RTP that provides confidentiality, message authentication, and replay protection for data and control packets RFC3711.  SRTP packets are encrypted using a session key, which is derived from a separate master key.  Master keys are derived and managed externally, e.g., via DTLS, as specified in RFC 5763 RFC5763, under the control of a signaling protocol such as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch. </ins>  <ins> 3.5.1. </ins>  <ins> SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity protection to RTP control (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 itself is left unencrypted to enable RTP header compression RFC3545. For RTCP packets, the first packet in the compound RTCP packet is partially encrypted, leaving the first eight octets of the header as cleartext 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. Packets are encrypted using session keys, which are ultimately derived from a master key and some 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 rollover 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. 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". 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. DTLS RFC5764 is commonly used as a way to perform mutual authentication and key agreement for SRTP RFC5763.  (Here, certificates marshal public keys between endpoints.  Thus, self- signed certificates may be used if peers do not mutually trust one another, as is common on the Internet.)  When DTLS is used, certificate fingerprints are transmitted out-of-band using SIP. Peers typically verify that DTLS-offered certificates match that which are offered over SIP.  This prevents active attacks on RTP, but not on the signaling (SIP or WebRTC) channel. 3.5.2. Optional replay protection with tunable replay windows. Out-of-order packet receipt. (RFC5763) Mandatory mutually authenticated key exchange. Partial encryption, protecting media payloads and control packets but not data packet headers. Optional authentication of data packets; mandatory authentication of control packets. 3.5.3. External key derivation and management mechanism or protocol, e.g., DTLS RFC5763. External signaling protocol to manage RTP parameters and locate and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb- security-arch. 3.6. ((TODO: write me)) 3.7. 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. 3.7.1. Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  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) I-D.ietf-tcpinc-tcpeno.  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. 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. 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. 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. 3.7.2. Forward-secure TCP payload encryption and integrity protection. Session caching and address-agnostic resumption. Connection re-keying. Application-level authentication primitive. 3.7.3. TCP TCP Encryption Negotiation Option (ENO) 3.8. WireGuard is a layer 3 protocol designed to complement or replace IPsec WireGuard.  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. 3.8.1. 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. </ins> WireGuard builds on Noise Noise for 1-RTT key exchange with identity hiding.  The handshake hides peer identities as per the SIGMA This cookie only proves IP address ownership.  Any rate limiting scheme can be applied to packets coming from non-spoofed addresses.  <ins> 3.8.2. </ins> Optional PSK-based session creation. Cookie-based DoS mitigation similar to DTLS and IKEv2.  <ins> 3.8.3. </ins> Datagram transport. Out-of-band key distribution and management. <ins> 3.9. MinimalT is a UDP-based transport security protocol designed to offer confidentiality, mutual authentication, DoS prevention, and connection mobility MinimalT.  One major goal of the protocol is to leverage existing protocols to obtain server-side configuration information used to more quickly bootstrap a connection.  MinimalT uses a variant of TCP's congestion control algorithm. 3.9.1. 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. 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 the connection establishment and packet encryption mechanisms are coupled. 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. 3.9.2. 0-RTT forward secrecy for new connections. DoS prevention by client-side puzzles. Tunnel-based mobility. (Transport Feature) Connection multiplexing between hosts across shared tunnels. (Transport Feature) Congestion control state is shared across connections between the same host pairs. 3.9.3. A DNS-like resolution service to obtain location information (an IP address) and ephemeral keys. A PKI trust store for certificate validation. </ins> 3.10.  <ins> 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. </ins> 3.10.1.  <ins> 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. </ins>  <ins> 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. </ins>  <ins> The use of only 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. </ins>  <ins> 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. </ins>  <ins> Unlike TCP, the server employs cookies to enable source validation. After receiving the client's initial packet, encrypted under the server's long-term public key, the 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. 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. 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. </ins> 3.10.2.  <ins> Forward-secure data encryption and authentication. </ins>  <ins> Per-packet public-key encryption. </ins>  <ins> 1-RTT session bootstrapping. </ins>  <ins> Connection mobility based on a client-chosen ephemeral identifier. </ins>  <ins> Connection establishment message padding to prevent traffic amplification. </ins>  <ins> Sender-chosen explicit nonces, e.g., based on a sequence number. </ins>  <ins> 3.10.3. </ins>  <ins> An unreliable transport protocol such as UDP. </ins> 4.


3.5. <del> SRTP - Secure RTP - is a profile for RTP that provides confidentiality, message authentication, and replay protection for data and control packets RFC3711.  SRTP packets are encrypted using a session key, which is derived from a separate master key.  Master keys are derived and managed externally, e.g., via DTLS, as specified in RFC 5763 RFC5763, under the control of a signaling protocol such as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch. </del>  3.5.1. SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity <del> protection to RTP control (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 itself is 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 cleartext 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. </del>  Packets are encrypted using session keys, which are ultimately <del> derived from a master key and some additional master salt and session </del>  salt.  SRTP packets carry a 2-byte sequence number to partially identify the unique packet index.  SRTP peers maintain a separate <del> rollover counter (ROC) for RTP data packets that is incremented </del>  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 and processed packet indices.  If a packet arrives with an index that matches one in the replay list, it is silently discarded. <del> DTLS RFC5764 is commonly used as a way to perform mutual authentication and key agreement for SRTP RFC5763.  (Here, certificates marshal public keys between endpoints.  Thus, self- signed certificates may be used if peers do not mutually trust one another, as is common on the Internet.)  When DTLS is used, certificate fingerprints are transmitted out-of-band using SIP. Peers typically verify that DTLS-offered certificates match that which are offered over SIP.  This prevents active attacks on RTP, but not on the signaling (SIP or WebRTC) channel. </del>  3.5.2. <del> Optional replay protection with tunable replay windows. Out-of-order packet receipt. (RFC5763) Mandatory mutually authenticated key exchange. </del> Partial encryption, protecting media payloads and control packets but not data packet headers. Optional authentication of data packets; mandatory authentication of control packets.  3.5.3. <del> External key derivation and management mechanism or protocol, e.g., DTLS RFC5763. </del>  <del> External signaling protocol to manage RTP parameters and locate and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb- security-arch. </del>  3.6.

This attempts to make the description of DTLS+SRTP keying less confusing.
The description of how DTLS is used for establishing SRTP connections is confusing: is mutual auth in DTLS ever used, or is an OOB fingerprint via SIP always used? The text here needs to be clarified.

3.5.  <ins> 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. </ins> 3.5.1. SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity  <ins> 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. </ins> Packets are encrypted using session keys, which are ultimately  <ins> derived from a master key and an additional master salt and session </ins> salt.  SRTP packets carry a 2-byte sequence number to partially identify the unique packet index.  SRTP peers maintain a separate  <ins> roll-over counter (ROC) for RTP data packets that is incremented </ins> 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 and processed packet indices.  If a packet arrives with an index that matches one in the replay list, it is silently discarded.  <ins> 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 signalling 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 signalling channel protects against active attacks on the media, provided the signalling can be trusted.  Signalling needs to be protected as described in, for example, SIP RFC3261 Authenticated Identity Management RFC4474 or the WebRTC security architecture I- D.ietf-rtcweb-security-arch, to provide complete system security. </ins> 3.5.2.  Partial encryption, protecting media payloads and control packets but not data packet headers. Optional authentication of data packets; mandatory authentication of control packets. <ins> Optional replay protection with tunable replay windows. Out-of-order packet receipt. Mutually authenticated key exchange </ins> 3.5.3.  <ins> External key derivation and management protocol, e.g., DTLS RFC5763. </ins>  <ins> External identity management protocol, e.g., SIP Authenticated Identity Management RFC4474, WebRTC Security Architecture I- D.ietf-rtcweb-security-arch. </ins> 3.6.


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 <del> dependency is unavailable.  In this context, an application dependency is one required from an application in order to function. </del>  5.1. Record or datagram confidentiality and integrity.  Forward-secure key establishment.  Public-key certificate based authentication.  Unilateral responder authentication. <del> Note that most systems provide defailt trust stores used to authenticate peers based on certificates.  In such systems, applications need not provide any trust information.  Applications running on systems without such a feature must necessary depend on applications for this information so as to authenticate peers. </del>  5.2.

As promised at IETF 103, here's a suggested definition of application dependency, to make it clearer what I'm talking about. I have also added dependencies for the mandatory features, so that it's clear for all features whether they have any application dependencies. In addition, I changed the heading of the section because the section does not actually talk about transport dependencies anymore. What do you think?
Yep, I agree. This change looks good. Thank you, NAME good with these changes.

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  <ins> dependency is unavailable. 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. </ins> 5.1. Record or datagram confidentiality and integrity. <ins> Application dependency: None. </ins> Forward-secure key establishment. <ins> Application dependency: None. </ins> Public-key certificate based authentication. <ins> 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. </ins> Unilateral responder authentication.  <ins> Application dependency: Application providing trust information, see above. </ins> 5.2.


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 <del> 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. </del>  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 <del> protocols such as Google QUIC, are both included despite overlapping </del>  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 This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. <del> The interfaces between these protocols and transports are described in transport-interface; the interfaces between these protocols and applications are described in application-interface. </del>  3.1. Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets <del> and RTP control protocol (RTCP) packets RFC3711. </del>  3.2.2. alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet <del> frames within a secure tunnel and can run over UDP or TCP. </del>  4.

This PR mainly changes the beginning of Section 3, Transport Security Protocol Descriptions. It substitutes the sentence on how the document is structured (which I moved to the Introduction) with a brief discussion on the classification we use in Section 3. This includes an explanation of the difference between handshake and record protocols as suggested by Ekr. Furthermore, this PR references DTLS-SRTP, renames "QUIC + TLS" to "IETF QUIC", and mentions that OpenVPN can use TLS as a handshake protocol.
Thank you!

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  <ins> identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. </ins> 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  <ins> protocols such as gQUIC, are both included despite overlapping </ins> 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 This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network.  <ins> These protocols are grouped based on where in the protocol stack they are implemented, which influences which parts of a packet they protect: Generic application payload, application payload for specific application-layer protocols, both application payload and transport headers, or entire IP packets. Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination with other protocols.  One major reason for this is that channel security protocols often consist of two components: A handshake protocol, which is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys. A record protocol, which is used to encrypt traffic using keys and parameters provided by the handshake protocol. For some protocols, such as tcpcrypt, these two components are tightly integrated.  In contrast, for IPsec, these components are implemented in separate protocols: AH and ESP are record protocols, which can use keys supplied by the handshake protocol IKEv2, by other handshake protocols, or by manual configuration.  Moreover, some protocols can be used in different ways: While the base TLS protocol as defined in RFC8446 has an integrated handshake and record protocol, TLS or DTLS can also be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake protocol can be used with a separate record layer, as in QUIC. </ins> 3.1. Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets  <ins> and RTP control protocol (RTCP) packets RFC3711.  SRTP can use different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or ZRTP RFC6189. </ins> 3.2.2. alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet  <ins> frames within a secure tunnel and can run over UDP or TCP.  For key establishment, OpenVPN can use TLS as a handshake protocol or pre- shared keys. </ins> 4.


Source Address Validation: The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application.  This involves sending a cookie exchange <del> to avoid DoS attacks.  Protocols: QUIC + TLS, DTLS, WireGuard </del>  DTLS QUIC  WireGuard 5.3.

Addresses
Comment from Ekr's review of -10: S 5.2. IKE has source address validation, no?
Right! I'll change that in my summary table in .

Source Address Validation: The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application.  This involves sending a cookie exchange  <ins> to avoid DoS attacks. </ins> DTLS QUIC <ins> IKEv2 </ins> WireGuard 5.3.


3.3.5. CurveCP CurveCP is a UDP-based transport security protocol from <del> 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. </del>  3.4. 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, <del> 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. </del>  3.4.3.

Addresses
Comment from Ekr'r review of -10: S 3.3.5. 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. This text is going to be confusing to people. Not to say that CurveCP is bad, and the primitives it uses are fast, but they're not any faster than those used by TLS, QUIC, or tcpcrypt. I think the consensus here is that it's not currently practical to have a general purpose transport protocol that doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). Reply from Kyle: Good point. We could discuss the tradeoff between performance and security that DJB was trying to achieve, but that is probably out-of-scope for this document, so we should stick to a value-free description (e.g., "based entirely on public key algorithms") and let it go with that.
LGTM!

3.3.5. CurveCP CurveCP is a UDP-based transport security protocol from  <ins> Daniel J.  Bernstein.  Unlike many other security protocols, it is based entirely upon public key algorithms.  CurveCP provides its own reliability for application data as part of its protocol. </ins> 3.4. 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,  <ins> which rely on Public Key Infrastructure (PKI) for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out-of-band, each of which is bound to one or more IP addresses.  Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility. </ins> 3.4.3.


alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet <del> frames within a secure tunnel and can run over UDP or TCP.  For key establishment, OpenVPN can use TLS as a handshake protocol or pre- shared keys. </del>  4. tcpcrypt <del> Packet Security Protocols: OpenVPN </del> 4.2. The following protocols all depend on the transport protocol to WireGuard  4.2.1. Of the protocols listed above that depend on the transport for

Addresses
No objection, but I don't know OpenVPN.
Comment from Ekr's review of -10: Packet Security Protocols: o OpenVPN Well, sort of. OpenVPN needs TCP for its key establishment phase but not its transport phase. That doesn't seem like that interesting a point to make here, as if TCP wasn't available, it could just cut over to DTLS.
Agreed: My notes on OpenVPN say that it can run completely over UDP, in which case it provides its own reliability layer for handshake and key exchange, and no reliability for data packets. I guess that means that OpenVPN does not have any transport dependencies, so deleting it from Section 4.1 is correct and I don't see any other place in Section 4 for it. I'd say stating it can run over either TCP or UDP is enough here, so this PR is sufficient.

alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet  <ins> frames within a secure tunnel and can run over either UDP or TCP. For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. </ins> 4. tcpcrypt  4.2. The following protocols all depend on the transport protocol to WireGuard <ins> OpenVPN </ins> 4.2.1. Of the protocols listed above that depend on the transport for


Address . IKE has mobility via MOBIKE (which makes ESP move, but it's more a property of IKE)
Yes, my impression was that we would keep the lists as well as the table?
Comment from Ekr's review of -10: o 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). How does this work in ESP, actually? DTLS sort of has this, in that it has a CID, but vague migration rules.
It may be better to mark this as IKEv2/ESP; it's MOBIKE that supports mobility.
This can be closed now, right?
Yup!
Interesting - so we do differentiate between ESP and IKEv2 here? (In Section 3.4.1 we say that "this document considers them together, since that is the most common pattern".) I'm okay with this and I've adjusted the summary table, which now has ESP and IKEv2 separately, in the other PR. As I'm not sure we want to put a reference into the summary table, I guess this means that we're keeping the protocol lists in addition to the summary table, which I'm also fine with.


WireGuard  Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites. IKEv2  Extensions (Application-Layer Protocol Negotiation): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN RFC7301. directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. <del> Explicit import: QUIC, ESP </del>  Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard IKEv2  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. used directly in conjunction with the record protocol. Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, <del> IKEv2 </del>  Direct export: TLS, DTLS, MinimalT

I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1

WireGuard <ins> OpenVPN </ins> Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites. IKEv2 <ins> OpenVPN </ins> Extensions (Application-Layer Protocol Negotiation): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN RFC7301. directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable.  <ins> Explicit import: QUIC, ESP, OpenVPN </ins> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard IKEv2 <ins> OpenVPN </ins> 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. used directly in conjunction with the record protocol. Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt,  <ins> IKEv2, OpenVPN </ins> Direct export: TLS, DTLS, MinimalT


QUIC  MinimalT Authentication Delegation: The application provides access to a IKEv2  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

Part of This addresses two of Ekr's comments about tcpcrypt in URL The remaining (tcpcrypt occurring before TCP reassembly) I believe is invalid.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not? Document: draft-ietf-taps-transport-security-URL This document is much improved. I appreciate you removing all the fine detail of each transport protocol. However, I think another pass is probably required. At a high level, I think your taxonomy is still problematic, especially when it comes to TLS/DTLS because they have been so widely used in coordination with other protocols (SRTP, SCTP, QUIC, EAP, etc.) So, it's simultaneously a full transport protocol (the original usage), an external key management protocol (OpenVPN), an embedded key management protocol (QUIC, and what's effectively a VPN protocol (SCTP over DTLS and AnyConnect VPN). Part of this can be fixed by just saying something like this and including DTLS in a few other places in the doc, but in general, the world is just complicated and so taxonomies are difficult. It would probably somewhat help to explain the common design for channel security protocols. Something like: In general, channel security protocols follow a common pattern: A handshake protocol is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys. A record protocol is used to encrypt traffic using keys and parameters provided by the handshake protocol. In some systems, such as IPsec, these protocols are separate: AH and ESP just assume some external source of keys and parameters; these are commonly supplied by IKEv2 but can also be supplied by some other protocol or manually configured. In other systems, these are tightly integrated, as in tcpcrypt. Some protocols can also be used in both configurations: the base TLS protocol as defined in [RFC8446] has an integrated handshake and record protocol, but TLS or DTLS can be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake can be used alone with s separate record layer, as in QUIC. S 3.2.1. You're going to want to mention DTLS-SRTP here, partly for the reasons I mentioned above but partly to help understand the situation with ZRTP. I.e., SRTP, like IPsec, just assumes that it has some external keying mechanism and DTLS and ZRTP both fill this role. S 3.3.1. I would just call this IETF QUIC, because QUICv1 is defined to use TLS. S 3.3.5. 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. This text is going to be confusing to people. Not to say that CurveCP is bad, and the primitives it uses are fast, but they're not any faster than those used by TLS, QUIC, or tcpcrypt. I think the consensus here is that it's not currently practical to have a general purpose transport protocol that doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). OpenVPN OpenVPN [OpenVPN] is a commonly used protocol designed as an alternative to IPsec. A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports. OpenVPN encapsulates either IP packets or Ethernet frames within a secure tunnel and can run over UDP or TCP. It's probably worth noting that OpenVPN uses SSL/TLS for handshake, as it illustrates the pattern above. Reliable Byte-Stream Transports The following protocols all depend upon running on a transport protocol that provides a reliable, in-order stream of bytes. This is typically TCP. Application Payload Security Protocols: o TLS Transport-Layer Security Protocols: o tcpcrypt This doesn't seem quite right, as tcpcrypt is run prior to the TCP reassembly algorithms. Packet Security Protocols: o OpenVPN Well, sort of. OpenVPN needs TCP for its key establishment phase but not its transport phase. That doesn't seem like that interesting a point to make here, as if TCP wasn't available, it could just cut over to DTLS. Pre-Connection Interfaces Configuration interfaces are used to configure the security protocols before a handshake begins or the keys are negotiated. This presentation seems pretty hard to follow, in that it's a lot of work to figure out which in the long list of protocols doesn't have this property. Maybe a summary table would help? Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches. o Authentication Delegation: The application provides access to a separate module that will provide authentication, using EAP for example. You don't list TLS, but what about EAP-TLS? I'm not following any of the text around import. This direct/explicit distinction seems arbitrary, and weird for QUIC, because QUIC doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated. S 5.2. IKE has source address validation, no? S 5.3. o 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. This seems like kind of a confusing section, I think partly because it ignores layering. The way I think of this is that we have an existing family of insecure protocols that have their own termination mechanisms (e.g., TCP FIN/RST). A security protocol that is under such a protocol (e.g., IPsec) doesn't need a secure termination mechanism because (a) the existing termination mechanism become secure and (b) it can just stop transmitting. By contrast, a security protocol that is above (TLS) or at the level of such a protocol (QUIC, tcpcrypt) needs its own secure termination mechanism, lest it be at the mercy of the transport. o 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). How does this work in ESP, actually? DTLS sort of has this, in that it has a CID, but vague migration rules.

QUIC <ins> tcpcrypt </ins> MinimalT Authentication Delegation: The application provides access to a IKEv2 <ins> tcpcrypt </ins> 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


Connection Termination: The security protocol may be instructed to tear down its connection and session information.  This is needed <del> by some protocols to prevent application data truncation attacks. </del>  TLS

Add half a sentence to Connection Termination to address , which complained that this part ignores layering. I guess IKEv2 is the only protocol there that is not at the same layer as TCP or above. So maybe for IKEv2, the Connection Termination interface prevents a different attack (at least I didn't find anything on data truncation for IKEv2), but I think that's okay. Data truncation is just an example and we don't need to enumerate all possible attacks.
Looks good!
Comment from Ekr's review of -10: S 5.3. o 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. This seems like kind of a confusing section, I think partly because it ignores layering. The way I think of this is that we have an existing family of insecure protocols that have their own termination mechanisms (e.g., TCP FIN/RST). A security protocol that is under such a protocol (e.g., IPsec) doesn't need a secure termination mechanism because (a) the existing termination mechanism become secure and (b) it can just stop transmitting. By contrast, a security protocol that is above (TLS) or at the level of such a protocol (QUIC, tcpcrypt) needs its own secure termination mechanism, lest it be at the mercy of the transport.

Connection Termination: The security protocol may be instructed to tear down its connection and session information.  This is needed  <ins> by some protocols, e.g., to prevent application data truncation attacks in which an attacker terminates an underlying insecure connection-oriented protocol to terminate the session. </ins> TLS


tcpcrypt Pre-Shared Key Import: Either the handshake protocol or the <del> 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. </del>  <del> Explicit import: QUIC, ESP, OpenVPN </del>  <del> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard </del>  <del> Non-importable: CurveCP </del>  5.2. IKEv2 <del> 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. </del>  <del> Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, IKEv2, OpenVPN </del>  <del> Direct export: TLS, DTLS, MinimalT </del>  <del> Non-exportable: CurveCP </del>  Key Expiration: The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based

Oh, and just double-checking: For PSK Export, SRTP and QUIC are a "No"? Because the old text said "TLS (for QUIC), DTLS (for SRTP)".
Yeah, I think that since QUIC and SRTP themselves don't export, but just use the export from inner protocols, this makes sense as is.
Comment from Ekr's review of -10: I'm not following any of the text around import. This direct/explicit distinction seems arbitrary, and weird for QUIC, because QUIC doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated.
NAME can you help on this one?
Ping NAME
We can do this for the export side of things, too.
Fixed in .
Thanks, looks good! Just suggesting one tweak in the wording for the import text.

tcpcrypt Pre-Shared Key Import: Either the handshake protocol or the  <ins> application directly can supply pre-shared keys for use in encrypting (and authenticating) communication with a peer. </ins>  <ins> TLS DTLS QUIC ESP IKEv2 OpenVPN tcpcrypt </ins>  <ins> MinimalT </ins>  <ins> WireGuard </ins> 5.2. IKEv2  <ins> Shared Secret Export: The handshake protocol may provide an interface for producing shared secrets for application-specific uses. TLS DTLS tcpcrypt </ins>  <ins> IKEv2 </ins>  <ins> OpenVPN </ins>  <ins> MinimalT </ins> Key Expiration: The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based


Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets <del> and RTP control protocol (RTCP) packets RFC3711.  SRTP can use different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or ZRTP RFC6189. </del>  <del> 3.2.2. </del>  <del> 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. </del>  3.3. DTLS <del> SRTP </del> ZRTP  Transport-Layer Security Protocols: QUIC Application Payload Security Protocols:  SRTP Packet Security Protocols: separate module that will provide authentication, using EAP for example. <del> SRTP </del> IKEv2 tcpcrypt DTLS <del> SRTP </del>  QUIC

This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.

Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets  <ins> and RTP control protocol (RTCP) packets RFC3711.  SRTP provides a record layer only, and requires a separate handshake protocol to provide key agreement and identity management. </ins>  <ins> The commonly used handshake protocol for SRTP is DTLS, in the form of DTLS-SRTP RFC5764.  This is an extension to DTLS that negotiates the use of SRTP as the record layer, and describes how to export keys for use with SRTP. </ins>  <ins> ZRTP RFC6189 is an alternative key agreement and identity management protocols for SRTP.  ZRTP Key agreement is performed using a Diffie- Hellman key exchange that runs on the media path.  This generates a shared secret that is then used to generate the master key and salt for SRTP. </ins> 3.3. DTLS  ZRTP <ins> SRTP </ins> Transport-Layer Security Protocols: QUIC Application Payload Security Protocols: <ins> DTLS when used as a handshake protocol for SRTP ZRTP </ins> SRTP Packet Security Protocols: separate module that will provide authentication, using EAP for example.  IKEv2 tcpcrypt DTLS  <ins> ZRTP </ins> QUIC


identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google <del> QUIC (gQUIC), 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.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. </del>  Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and Packet Security Protocols: <del> IKEv2 and ESP </del>  WireGuard Packet Security Protocols: <del> IKEv2 and ESP </del>  4.3. a separate module that will provide authentication, using EAP for example. <del> IKEv2 </del>  tcpcrypt ESP <del> IKEv2 </del>  OpenVPN QUIC <del> IKEv2 </del>  WireGuard MinimaLT <del> IKEv2 </del>  OpenVPN MinimaLT <del> IKEv2 </del>  Shared Secret Export (PSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific tcpcrypt <del> IKEv2 </del>  OpenVPN CurveCP <del> IKEv2 </del>  WireGuard

Address
URL Hi, I concur. However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". Regards, Valery.

identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google  <ins> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport- interface and the interfaces between these protocols and applications in application-interface. </ins> Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and Packet Security Protocols:  <ins> IPsec </ins> WireGuard Packet Security Protocols:  <ins> IPsec </ins> 4.3. a separate module that will provide authentication, using EAP for example.  <ins> IPsec </ins> tcpcrypt ESP  <ins> IPsec </ins> OpenVPN QUIC  <ins> IPsec </ins> WireGuard MinimaLT  <ins> IPsec </ins> OpenVPN MinimaLT  <ins> IPsec </ins> Shared Secret Export (PSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific tcpcrypt  <ins> IPsec </ins> OpenVPN CurveCP  <ins> IPsec </ins> WireGuard


identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google <del> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport- interface and the interfaces between these protocols and applications in application-interface. 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 gQUIC, 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. </del>  Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH RFC4302 are excluded from this survey.  TCP-AO adds authenticity surfaces between security protocols and transport protocols, and between security protocols and applications. <del> 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 </del>  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 <del> TLS, restrict the set of transport protocols that can be used to </del>  those that offer a reliable stream of bytes. Defining the common interfaces that security protocols provide to Transport Feature: a specific end-to-end feature that the transport layer provides to an application.  Examples include <del> confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. </del>  Transport Service: a set of Transport Features, without an association to any given framing protocol, which provides functionality to an application.  Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire.  A Transport Protocol services an application. use with SRTP. ZRTP RFC6189 is an alternative key agreement and identity management <del> protocols for SRTP.  ZRTP Key agreement is performed using a Diffie- </del>  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. VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet frames within a secure tunnel and can run over either UDP or TCP. <del> For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. </del>  4. OpenVPN <del> Extensions (Application-Layer Protocol Negotiation) (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN RFC7301. </del>  TLS

This PR has fixes for Barry's and Robers's comments, which are all editorial. However, please double-check and state an opinion on the definition of a Transport Services system and on the attempt to provide more context to make the document easier to understand for readers not yet familiar with TAPS.
COMMENT: As incoming AD I found that document really useful and informative - thank you. As a minor nit, I found the English around the usage of the term "Transport Services", that I wasn't familiar with prior to reading this document, slightly tricky to parse in the introduction, particularly because the term isn't defined until the Terminology in section 3. E.g. in the second paragraph it isn't clear to me what a "Transport Services system" real means. Possibly replace "a Transport Services system may need to support" with "a Transport Service may need to support"? Similarly, perhaps change " One of the goals of Transport Services is to define a common interface for using transport protocols" to " One of the goals of Transport Service definitions is to define a common interface for using transport protocols"?
Addressing this issue, I realized that we do not actually define "Transport Services system" anywhere in -arch, or -interface. I usually take it to just be a synonym of "TAPS implementation". Initial proposal for this draft (which I would add to Section 3): "Transport Services system: a software component that exposes an interface to different Transport Services to an application." Do you agree? I'm also going to provide more context in the introduction to make the document easier to understand for people not yet familiar with TAPS.
COMMENT: Thanks for this helpful document. Just some editorial comments beyond what others have mentioned: — Section 1 — It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. It’s funny that this carefully expands every abbreviation except “SRTP”. Please do that one too. Ubiquitous IETF protocols such as (D)TLS, as well as non-standard protocols such as gQUIC, are both included The word “both” doesn’t work here. I think a reasonable fix is just to remove the single word. Maybe a better fix is to slightly reword, as, “Ubiquitous IETF protocols such as (D)TLS are included, and so are non-standard protocols such as gQUIC, despite...” — Section 1.1 — 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 Number agreement: make it “restricts” to match the singular subject “a security protocol”. — Section 2 — Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. You don’t need both “examples include” and “etc.”; I suggest eliminating the latter (and sticking in an “and”). — Section 3.1.1 — to marshal (possibly encrypted) data from one peer to the other. Possibly? I understand you’re covering the handshake there as well, but for a summary as (reasonably) brief as this I think it’s misleading to say “possibly”. — Section 3.2.1 — ZRTP [RFC6189] is an alternative key agreement and identity management protocols for SRTP. Number agreement: “protocol” — Section 3.4.3 — For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. This reads oddly, as though there are two things OpenVPN can use TLS for. I would make it, “URL it can use pre-shared keys.” — Section 5.1 — Extensions (Application-Layer Protocol Negotiation) (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN [RFC7301]. Isn’t the expansion of “ALPN” misplaced here?

identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google  <ins> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. A Transport Services system exposes an interface for applications to access various (secure) transport protocol features.  The security protocols included in this survey represent a superset of functionality and features a Transport Services system may need to support, both internally and externally (via an API) for applications I-D.ietf-taps-arch.  Ubiquitous IETF protocols such as (D)TLS, as well as non-standard protocols such as gQUIC, are included despite overlapping features.  As such, this survey is not limited to protocols developed within the scope or context of the IETF.  Outside of this candidate set, protocols that do not offer new features are omitted.  For example, newer protocols such as WireGuard make unique design choices that have implications and limitations on application usage.  In contrast, protocols such as ALTS ALTS are omitted since they do not provide interfaces deemed unique. </ins> Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH RFC4302 are excluded from this survey.  TCP-AO adds authenticity surfaces between security protocols and transport protocols, and between security protocols and applications.  <ins> One of the goals of the Transport Services effort is to define a common interface for using transport protocols that allows software using transport protocols to easily adopt new protocols that provide </ins> 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  <ins> TLS, restricts the set of transport protocols that can be used to </ins> those that offer a reliable stream of bytes. Defining the common interfaces that security protocols provide to Transport Feature: a specific end-to-end feature that the transport layer provides to an application.  Examples include  <ins> confidentiality, reliable delivery, ordered delivery, and message- versus-stream orientation. </ins> Transport Service: a set of Transport Features, without an association to any given framing protocol, which provides functionality to an application. <ins> Transport Services system: a software component that exposes an interface to different Transport Services to an application. </ins> Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire.  A Transport Protocol services an application. use with SRTP. ZRTP RFC6189 is an alternative key agreement and identity management  <ins> protocol for SRTP.  ZRTP Key agreement is performed using a Diffie- </ins> 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. VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet frames within a secure tunnel and can run over either UDP or TCP.  <ins> For key establishment, OpenVPN can either use TLS as a handshake protocol or use pre-shared keys. </ins> 4. OpenVPN  <ins> Extensions (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as Application-Layer Protocol Negotiation (ALPN) RFC7301. </ins> TLS


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 <del> usage.  In contrast, protocols such as ALTS ALTS are omitted since they do not provide interfaces deemed unique. Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH RFC4302 are excluded from this survey.  TCP-AO adds authenticity protections to long-lived TCP connections, e.g., replay protection with per-packet Message Authentication Codes.  (This protocol obsoletes TCP MD5 "signature" options specified in RFC2385.)  One prime use case of TCP-AO is for protecting BGP connections. Similarly, AH adds per-datagram authenticity and adds similar replay protection.  Despite these improvements, neither protocol sees general use and both lack critical properties important for emergent transport security protocols: confidentiality, privacy protections, and agility.  Such protocols are thus omitted from this survey. </del>  1.1. 3. <del> This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. These protocols are grouped based on where in the protocol stack they are implemented, which influences which parts of a packet they protect: Generic application payload, application payload for specific application-layer protocols, both application payload and transport headers, or entire IP packets. </del>  Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination 5. <del> This section describes the interface surface exposed by the security </del>  protocols described above.  We partition these interfaces into pre- connection (configuration), connection, and post-connection interfaces, following conventions in I-D.ietf-taps-interface and I- MinimaLT Authentication Delegation (AD): The application provides access to <del> a separate module that will provide authentication, using EAP for example. </del>  IPsec

Addresses and
== DISCUSS == I question the inclusion of CurveCP in the mix as per URL it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3. (and I hope to be corrected about CurveCP IPv6 support). COMMENT: Please respond to the IoT-directorate review by Mohit: URL Please respond to the INT-DIR review by Brian: URL + Gorry Fairhurst's about GRE Generic comment about the intended transport: all protocols analyzed in this document are point to point (no multicast), this should probably be mentioned in the introduction. -- Section 1 -- Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when "security protocol" is defined. -- Section 3 -- Use the wording of "record protocol" generically while the term "record protocol" is defined in section 2 as a blocked data transport (like in TLS). Suggest the use of "data transfer protocol" ? An important property of such protocols is to be able to traverse a NAPT box (that I hate)... I suggest to mention whether the analyzed protocols support NAT-traversal in this description section or even in the analysis parts as having a different view (application and network layers seeing possibly different IP addresses so a potential impact on the API).
From Magnus: Eric and I have discussed this and the proposal is a clarifying change to the initial statement in Section 3: OLD: This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. NEW: This section contains brief transport and security descriptions of the various security protocols currently used to protect data being sent over a network. The purpose of this change to clarify that these descriptions are only concerning relevant aspects of transport and security. Are the WG and authors ok with the above change?
From Gorry: I think GRE (the one I know more) should be mentioned as existing somehow. ... even if the WG doesn't want to add an analysis of GRE! A suggested starting text blob proposal for GRE could be: Generic Routing Encapsulation [RFC2784] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. GRE tunnels do not by default provide security features. [RFC2890] describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header to implement security functions. [RFC8086] specifies a method of encapsulating network protocol packets using GRE in UDP. GRE can be used in combination with IPsec (see RFC2890).
Just a note: We're not addressing his comment on including NAT traversal as a feature, right? I think a good explanation for this is that with TAPS we can do racing, e.g., if a secure transport protocol does not work because of NAT, we might use the same protocol but tunneled over UDP. Thus the problem of NAT traversal can be orthogonal to what we describe in our draft.
Maybe change "of the various" to "of various", since otherwise it can be read as suggesting these are all the security protocols used.
NAME applied your suggested change!
NAME Yes, let's just comment in our email response.
Major issues: The document header says that this document is about interfaces between security protocols and transport services. Yet, later on, I find that the document is also discussing the interfaces between security protocols and applications. Perhaps you could add 'applications' to the title -> 'Interaction Between Applications, Security Protocols, and Transport Services' Editorial issues: Instead of saying 'This protocol obsoletes TCP MD5 "signature" options', can we say 'TCP-AO obsoletes....' to avoid confusion of what is 'this' Please expand 'and IPsec AH [RFC4302]' -> IP Authentication Header Are you talking about cryptographic agility here 'security protocols: confidentiality, privacy protections, and agility.' ? Consider changing 'interface surface exposed '-> interface exposed by'. Otherwise it sounds too similar to attack surface exposed. Expand EAP and reference RFC3748. - Perhaps you could say that Source Address Validation (SAV) to prevent DoS is relevant for protocols that use unreliable transport?
Regarding the title change, I think we can not change this, as "Transport Services" is by definition the interaction between applications and transports; we're adding security to the mix. The first sentence of the abstract already mentions applications.
Should be covered by
Looks good so far, modulo one typo. I was wondering if we want to include "integrity protection" to our definition of Security Protocol, too, as Eric suggested. But that sentence says "such as", so perhaps it's fine if we don't enumerate all possible features. Also, Eric suggested we change our generic use of the term "record protocol", as our definition in Section 2 clashes with it. Maybe we want to change the definition in Section 2 instead to match our use and remove the "Record" definition? I don't think we actually use "Record" as "Framed protocol messages" in the rest of the document, do we?NAME LGTM with a couple nits! Reviewer: Mohit Sethi Review result: Ready with Nits This document provides a summary of common security protocols. It then discusses the interfaces that exist between applications and security protocols as well as security protocols and transport services. Major issues: The document header says that this document is about interfaces between security protocols and transport services. Yet, later on, I find that the document is also discussing the interfaces between security protocols and applications. Perhaps you could add 'applications' to the title -> 'Interaction Between Applications, Security Protocols, and Transport Services' Editorial issues: Instead of saying 'This protocol obsoletes TCP MD5 "signature" options', can we say 'TCP-AO obsoletes....' to avoid confusion of what is 'this' - Please expand 'and IPsec AH [RFC4302]' -> IP Authentication Header - Are you talking about cryptographic agility here 'security protocols: confidentiality, privacy protections, and agility.' ? - Consider changing 'interface surface exposed '-> interface exposed by'. Otherwise it sounds too similar to attack surface exposed. - Expand EAP and reference RFC3748. - Perhaps you could say that Source Address Validation (SAV) to prevent DoS is relevant for protocols that use unreliable transport?
Reviewer: Brian Haberman Review result: Ready with Issues This document is a survey of network security protocols and their interaction with transport and application protocols. It is clearly written and easy to read. I have a minor comment on the contents of this draft. It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft. Some notable omissions include SSH, L2TP, and GRE. These seem like interesting omissions given their popularity in a number of deployment scenarios. Not a showstopper in my opinion, but interesting to note.

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  <ins> usage.  In contrast, protocols such as SSH RFC4253, GRE RFC2890, L2TP ?RFC 5641, and ALTS ALTS are omitted since they do not provide interfaces deemed unique. Authentication-only protocols such as TCP-AO RFC5925 and IPsec Authentication Header (AH) RFC4302 are excluded from this survey. TCP-AO adds authentication to long-lived TCP connections, e.g., replay protection with per-packet Message Authentication Codes. (TCP-AO obsoletes TCP MD5 "signature" options specified in RFC2385.) One primary use case of TCP-AO is for protecting BGP connections. Similarly, AH adds per-datagram authentication and integrity, along with replay protection.  Despite these improvements, neither protocol sees general use and both lack critical properties important for emergent transport security protocols, such as confidentiality and privacy protections.  Such protocols are thus omitted from this survey. This document only surveys point-to-point protocols; multicast protocols are out of scope. </ins> 1.1. 3.  <ins> This section contains brief transport and security descriptions of the various security protocols currently used to protect data being sent over a network.  These protocols are grouped based on where in the protocol stack they are implemented, which influences which parts of a packet they protect: Generic application payload, application payload for specific application-layer protocols, both application payload and transport headers, or entire IP packets. </ins> Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination 5.  <ins> This section describes the interface exposed by the security </ins> protocols described above.  We partition these interfaces into pre- connection (configuration), connection, and post-connection interfaces, following conventions in I-D.ietf-taps-interface and I- MinimaLT Authentication Delegation (AD): The application provides access to  <ins> a separate module that will provide authentication, using Extensible Authentication Protocol (EAP) RFC3748 for example. </ins> IPsec