Change:
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?

Discussion:
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> <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. <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> <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 <del> TLS, restrict the set of transport protocols that can be used to </del> <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 <del> confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. </del> <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 <del> protocols for SRTP.  ZRTP Key agreement is performed using a Diffie- </del> <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. <del> For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. </del> <ins> For key establishment, OpenVPN can either use TLS as a handshake protocol or use pre-shared keys. </ins> 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> <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