Subject: [Taps] Benjamin Kaduk's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 15:35:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-taps-transport-security-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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))").

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Apr 2020 10:23:51 -0700

Hi Ben,

Thanks for the detailed review! You can find an updated version of the document here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html <https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html>

We did rename IKEv2 + ESP to simply IPsec, at the recommendation of ipsecme. We explain those individual protocols in the IPsec section, but do not reference them elsewhere.

Responses to your specific points inline.

> On Apr 8, 2020, at 3:35 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

Thanks for the pointer to that document. We did review it (and I for one had not seen it before!). We chose not to add a reference for now, as there didn’t seem any obvious place to put a reference. That document seems to specify a specific generic API, whereas we’re more talking about how the shape of security protocols fit into transports.
> mentions in Sections 1 and 3, with the first reference occuring in

We’ve moved the reference for this earlier in the document.
> nit: "implications for" and "limitations on”.

Indeed! Fixed.
> clarify what was intended?

Removed this, and just list confidentiality and privacy protections now.
> SSH host key fingerprints, etc.

Good point! Added:

"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."
> Should we reference RFC 8095 at the appropriate definitions [that we

Added the reference.
> (whether directly or with an intermediating security protocol?)

Used your suggested text.

> handshake has sufficiently progressed, encrypt, data from one peer to

Used your suggested text.
> DTLS whereas it is inherently provided in TLS.

We added a reference to DTLS 1.3, and shameless lift the text from that draft:

"DTLS modifies the protocol to make sure it can still provide equivalent security guarantees to TLS with the exception of order protection/non-replayability."
> a reference for IPsec(!).

Good point, fixed!
> certificates in all cases, so I also think the "e.g." is appropriate.

Fixed.
> I'm not sure I understand the intent of using the word "delegate" here.

Changed to "The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.”
> aren't currently referencing DTLS 1.3).

Added a reference to DTLS 1.3 and listed it here.
> (leakage via encryption))").

Used your suggested text.

Thanks,
Tommy

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Apr 2020 14:24:36 -0700

Hi Tommy,

also inline.

> Thanks for the pointer to that document. We did review it (and I for one had not seen it before!). We chose not to add a reference for now, as there didn’t seem any obvious place to put a reference…

Thanks for taking a look.  I can't say I'm surprised that it ended up not
really matching what you're doing, but think it was worth the time to
check.

> "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 thes…

Thanks.

> "DTLS modifies the protocol to make sure it can still provide equivalent security guarantees to TLS with the exception of order protection/non-replayability."

Oh good, someone other than me has put some thought into whether that's the
only point of divergence, becuase I did not put a huge amount of thought
into it...
Reusing the text from DTLS 1.3 sounds reasonable (though I guess my AD
Evaluation of DTLS 1.3 could in theory produce changes ... all the more
reason to clear that part of my backlog)

> Changed to "The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.”

Ah, thanks.  You would think that the name of the bullet point being
"source address validation" would key me into using that interpretation of
"validation" and not a cryptographic one, and yet I still managed to
confuse myself the first time I read the old text.

Thanks for the updates!

-Ben