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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 22:48:44 -0700

Barry Leiba 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:
----------------------------------------------------------------------

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?

---

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

Hi Barry,

Thanks for the 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>

Responses to your individual points inline.

> On Apr 7, 2020, at 10:48 PM, Barry Leiba via Datatracker <[email-masked]> wrote:
> 

Expanded!
> such as gQUIC, despite...”

Fixed by removing the word.
> Number agreement: make it “restricts” to match the singular subject “a security

Fixed.
> latter (and sticking in an “and”).

Fixed.
> summary as (reasonably) brief as this I think it’s misleading to say “possibly”.

This is now:

"The record protocol is used to marshal and, once the handshake has sufficiently progressed, encrypt, data from one peer to the other. "
> Number agreement: “protocol”

Fixed!
> would make it, “...or it can use pre-shared keys.”

Changed to:

"For key establishment, OpenVPN can either use TLS as a handshake protocol or use pre-shared keys."
> Isn’t the expansion of “ALPN” misplaced here?

This is now written out in expanded form "Application-Layer Protocol Negotiation (ALPN) [RFC7301]"

Thanks,
Tommy

---

From: Barry Leiba <[email-masked]>
Date: Wed, 22 Apr 2020 13:52:18 -0400

Thanks, Tommy... all good!

Barry

On Wed, Apr 22, 2020 at 1:11 PM Tommy Pauly <[email-masked]> wrote:
> https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html
>