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 protected]> > 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
