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