A Survey of the Interaction between Security Protocols and Transport Services
draft-ietf-taps-transport-security-12

Not much that I can add, other than that I really like these type of documents - the IETF has a huge number of documents, and it's really hard for people to know where to start, especially with this sort of topic.

Thank you for the work put into this document. It is really easy to read.

After discussion with Magnus and Barry, I have cleared my DISCUSS but I still hope for a fix to my previous DISCUSS

Please find below some non-blocking COMMENTs. An answer will still be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== previous DISCUSS ==

I question the inclusion of CurveCP in the mix as per https://curvecp.org/addressing.html it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3 or rename section 3 from "protocol descriptions" into something less exhaustive.

(and I hope to be corrected about CurveCP IPv6 support).

== COMMENT ==

Please respond to the IoT-directorate review by Mohit: https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR review by Brian: https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I + 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).

This document should be tagged as replacing draft-pauly-taps-transport-security.

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, “...or 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?

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 don'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 can'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 doesn'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
aren'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))").

Nice document!