Draft: draft-ietf-taps-transport-security

Commentary: Completes . 
 could we get this reviewed before the interim ? 
 Updated the table and resolved the merge conflict . I think this is good to go now . 
 I do wonder whether the Generic Security Service API ( RFC 2743 ) was considered by the WG in the production of this document . It reflects a somewhat dated snapshot of what was believed to be necessary security APIs , but may not be entirely without value for this type of survey . It 's a little surprising to not list a reference for QUIC in its mentions in Sections 1 and 3 , with the first reference occuring in Section 3.3.1 . Section 1 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 nit : " implications for " and " limitations on " . 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 . I do n't think I see how TCP - AO and IPsec AH lack " agility " . Could you clarify what was intended ? Section 1.2 It is not a goal to allow software implementations to automatically switch between different security protocols , even where their interfaces to transport and applications are equivalent . Even between versions , security protocols have subtly different guarantees and vulnerabilities . [ ... ] Another impactful distinction between security protocols is in how they name and authenticate the communications peer -- I ca n't imagine writing a useful API that tries to abstract out the X.509 DNS - ID naming for TLS , SSH host key fingerprints , etc . Section 2 Should we reference RFC 8095 at the appropriate definitions [ that we duplicate from it ] ? 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 . ( whether directly or with an intermediating security protocol ? ) Section 3.1.1 protocol . The handshake protocol is used to authenticate peers , negotiate protocol options , such as cryptographic algorithms , and derive session - specific keying material . The record protocol is used to marshal ( possibly encrypted ) data from one peer to the other . My inference is that the " possibly encrypted " is supposed to refer to the encryption performed by the TLS record layer itself , as opposed to having already - encrypted data supplied to TLS as " Application Data " . If correct , I 'd suggest rewording to " is used to marshal and , once the handshake has sufficiently progressed , encrypt , data from one peer to the other " . Section 3.1.2 DTLS does n't provide " the same security guarantees as TLS " in the general case . Specifically , redord replay detection is only optional in DTLS whereas it is inherently provided in TLS . Section 3.4.2 WireGuard is an IP - layer protocol designed as an alternative to IPsec [ WireGuard ] for certain use cases . It uses UDP to encapsulate IP Please move the location of the reference ; it currently scans like it 's a reference for IPsec ( ! ) . Section 5.1 Identities and Private Keys ( IPK ): The application can provide its identities ( certificates ) and private keys , or mechanisms to access these , to the security protocol to use during handshakes . I think it would be more accurate to say " provide its identity , credentials ( e.g. , certificates ) , and private keys " -- a certificate is not exactly an identity , but rather an attestation thereof provided by a ( nominally ) trusted authority . Not all security protocols use certificates in all cases , so I also think the " e.g. " is appropriate . Section 5.2 Source Address Validation ( SAV ): 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 to avoid DoS attacks . I 'm not sure I understand the intent of using the word " delegate " here . Mobility Events ( ME ): 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 ) . I think it 's expected that DTLS 1.3 will do this ( though I note that you are n't currently referencing DTLS 1.3 ) . Section 8 omitted from this survey . All security protocols surveyed generally improve privacy by reducing information leakage via encryption . nit : I suggest " improve privacy by using encryption to reduce information leakage " ( to avoid the misparse of " reducing ( information ( leakage via encryption ) ) " ) . 
 For DTLS , we can quote the abstract " The DTLS protocol is based on the Transport Layer Security ( TLS ) protocol and provides equivalent security guarantees . " 
 The DTLS 1.3 protocol is intentionally based on the Transport Layer Security ( TLS ) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non - replayability . Datagram semantics of the underlying transport are preserved by the DTLS protocol . 
  mobility as DTLS 1.3 
 Looks good to me , modulo a few nits and a summary table update . Approved pending the table update fix from
Paragraph (version A):
design choices that have implications and limitations on application
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.
Paragraph (version B):
design choices that have implications for and limitations on
application 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.
Paragraph (version B):
Different security protocols also can use incompatible notions of
peer identity and authentication, and cryptographic options.  It is
not a goal to identify a common set of representations for these
concepts.
Paragraph (version A):
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.
Paragraph (version B):
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,
whether directly or in conjunction with a security protocol.
Paragraph (version A):
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.
Paragraph (version B):
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 I-D.ietf-quic-transport.
Paragraph (version A):
TLS (Transport Layer Security) RFC8446 is a common protocol used to
establish a secure session between two endpoints.  Communication over
this session "prevents eavesdropping, tampering, and message
forgery."  TLS consists of a tightly coupled handshake and record
protocol.  The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material.  The record protocol is used
to marshal (possibly encrypted) data from one peer to the other.
This data may contain handshake messages or raw application data.
Paragraph (version A):
DTLS (Datagram Transport Layer Security) RFC6347 is based on TLS, but
differs in that it is designed to run over unreliable datagram
protocols like UDP instead of TCP.  DTLS modifies the protocol to
make sure it can still provide the same security guarantees as TLS
even without reliability from the transport.  DTLS was designed to be
as similar to TLS as possible, so this document assumes that all
properties from TLS are carried over except where specified.
Paragraph (version B):
TLS (Transport Layer Security) RFC8446 is a common protocol used to
establish a secure session between two endpoints.  Communication over
this session "prevents eavesdropping, tampering, and message
forgery."  TLS consists of a tightly coupled handshake and record
protocol.  The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material.  The record protocol is used
to marshal and, once the handshake has sufficiently progressed,
encrypt, data from one peer to the other.  This data may contain
handshake messages or raw application data.
Paragraph (version B):
DTLS (Datagram Transport Layer Security) RFC6347 I-D.ietf-tls-dtls13
is based on TLS, but differs in that it is designed to run over
unreliable datagram protocols like UDP instead of TCP.  DTLS modifies
the protocol to make sure it can still provide equivalent security
guarantees to TLS with the exception of order protection/non-
replayability.  DTLS was designed to be as similar to TLS as
possible, so this document assumes that all properties from TLS are
carried over except where specified.
Paragraph (version A):
WireGuard is an IP-layer protocol designed as an alternative to IPsec
WireGuard for certain use cases.  It uses UDP to encapsulate IP
datagrams between peers.  Unlike most transport security protocols,
which rely on 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.
Paragraph (version B):
WireGuard WireGuard is an IP-layer protocol designed as an
alternative to IPsec for certain use cases.  It uses UDP to
encapsulate IP datagrams between peers.  Unlike most transport
security protocols, 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.
Paragraph (version A):
Identities and Private Keys (IPK): The application can provide its
identities (certificates) and private keys, or mechanisms to
access these, to the security protocol to use during handshakes.
Paragraph (version B):
Identities and Private Keys (IPK): The application can provide its
identity, credentials (e.g., certificates), and private keys, or
mechanisms to access these, to the security protocol to use during
handshakes.
Paragraph (version A):
Source Address Validation (SAV): 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 to avoid DoS attacks.
Paragraph (version B):
Source Address Validation (SAV): The handshake protocol may
interact with the transport protocol or application to validate
the address of the remote peer that has sent data.  This involves
sending a cookie exchange to avoid DoS attacks.
Paragraph (version A):
Analysis of how features improve or degrade privacy is intentionally
omitted from this survey.  All security protocols surveyed generally
improve privacy by reducing information leakage via encryption.
However, varying amounts of metadata remain in the clear across each
protocol.  For example, client and server certificates are sent in
cleartext in TLS 1.2 RFC5246, whereas they are encrypted in TLS 1.3
RFC8446.  A survey of privacy features, or lack thereof, for various
security protocols could be addressed in a separate document.
Paragraph (version B):
Analysis of how features improve or degrade privacy is intentionally
omitted from this survey.  All security protocols surveyed generally
improve privacy by using encryption to reduce information leakage.
However, varying amounts of metadata remain in the clear across each
protocol.  For example, client and server certificates are sent in
cleartext in TLS 1.2 RFC5246, whereas they are encrypted in TLS 1.3
RFC8446.  A survey of privacy features, or lack thereof, for various
security protocols could be addressed in a separate document.