Draft: draft-ietf-taps-transport-security

Commentary: This PR has fixes for  '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 was n't familiar with prior to reading this document , slightly tricky to parse in the introduction , particularly because the term is n't defined until the Terminology in section 3 . E.g. in the second paragraph it is n'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 ) ,  ( 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 ” does n’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 do n’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 —  [ 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 , “ 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 ] . Is n’t the expansion of “ ALPN ” misplaced here ?
Paragraph (version A):
Services and features provided by transport protocols have been
cataloged in RFC8095.  This document supplements that work by
surveying commonly used and notable network security protocols, and
identifying the 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 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.
Paragraph (version A):
Selected protocols represent a superset of functionality and features
a Transport Services system may need to support, both internally and
externally (via an API) for applications I-D.ietf-taps-arch.
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
protocols such as 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.
Paragraph (version B):
Services and features provided by transport protocols have been
cataloged in RFC8095.  This document supplements that work by
surveying commonly used and notable network security protocols, and
identifying the 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 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.
Paragraph (version B):
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.
Paragraph (version A):
One of the goals of Transport Services is to define a common
interface for using transport protocols that allows software using
transport protocols to easily adopt new protocols that provide
similar feature-sets.  The survey of the dependencies security
protocols have upon transport protocols can guide implementations in
determining which transport protocols are appropriate to be able to
use beneath a given security protocol.  For example, a security
protocol that expects to run over a reliable stream of bytes, like
TLS, restrict the set of transport protocols that can be used to
those that offer a reliable stream of bytes.
Paragraph (version B):
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
similar feature-sets.  The survey of the dependencies security
protocols have upon transport protocols can guide implementations in
determining which transport protocols are appropriate to be able to
use beneath a given security protocol.  For example, a security
protocol that expects to run over a reliable stream of bytes, like
TLS, restricts the set of transport protocols that can be used to
those that offer a reliable stream of bytes.
Paragraph (version A):
Transport Feature: a specific end-to-end feature that the
transport layer provides to an application.  Examples include
confidentiality, reliable delivery, ordered delivery, message-
versus-stream orientation, etc.
Paragraph (version B):
Transport Feature: a specific end-to-end feature that the
transport layer provides to an application.  Examples include
confidentiality, reliable delivery, ordered delivery, and message-
versus-stream orientation.
Paragraph (version B):
Transport Services system: a software component that exposes an
interface to different Transport Services to an application.
Paragraph (version A):
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.
Paragraph (version B):
ZRTP RFC6189 is an alternative key agreement and identity management
protocol 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.
Paragraph (version A):
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 either UDP or TCP.
For key establishment, OpenVPN can use TLS as a handshake protocol or
pre-shared keys.
Paragraph (version B):
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 either UDP or TCP.
For key establishment, OpenVPN can either use TLS as a handshake
protocol or use pre-shared keys.
Paragraph (version A):
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.
Paragraph (version B):
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.