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

[Tommy Pauly <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.

Expanded!
> 
>   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...”

Fixed by removing the word.
> 
> — 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”.

Fixed.
> 
> — 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”).

Fixed.
> 
> — 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”.

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. "
> 
> — Section 3.2.1 —
> 
>   ZRTP [RFC6189] is an alternative key agreement and identity
>   management protocols for SRTP.
> 
> Number agreement: “protocol”

Fixed!
> 
> — 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.”

Changed to:

"For key establishment, OpenVPN can either use TLS as a handshake protocol or 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?

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

Thanks,
Tommy