Ballot for draft-ietf-taps-transport-security
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
{Yes} [nits] S4.3 * s/Specific,/Specifically,/ * s/a dependencies/a dependency ?/ S5.3 * Does https://tools.ietf.org/html/rfc8446#section-4.6.3 count as supporting Key Expiration? Maybe not because the send is expected to observe the need to rekey and do so, rather than something in the record protocol itself. Is that a correct reading?
This is a really useful summary, especially for people without deep background in transport security. It'll make a great reference document. Section 4.3: * "Specific" should be "Specifically" * "They have a dependencies on" -- should be "dependency"
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).
To a non-expert it struck me as a bit odd that Dan Bernstein is mentioned as the designer of CurveCP but no one is mentioned as the designer of MinimalT.
These taps Informational RFCs are going to be bound together and make a great textbook someday. One nit: In section 5.3, you note that TLS supports key export. IIRC, this is only TLS 1.3. It might be worthwhile to specify it is 1.3 only.
As incoming AD I found that document really useful and informative - thank you. As a minor nit, I found the English around the usage of the term "Transport Services", that I wasn't familiar with prior to reading this document, slightly tricky to parse in the introduction, particularly because the term isn't defined until the Terminology in section 3. E.g. in the second paragraph it isn't clear to me what a "Transport Services system" real means. Possibly replace "a Transport Services system may need to support" with "a Transport Service may need to support"? Similarly, perhaps change " One of the goals of Transport Services is to define a common interface for using transport protocols" to " One of the goals of Transport Service definitions is to define a common interface for using transport protocols"?
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!