Document: draft-ietf-taps-transport-security-10.txt This document is much improved. I appreciate you removing all the fine detail of each transport protocol. However, I think another pass is probably required.
At a high level, I think your taxonomy is still problematic, especially when it comes to TLS/DTLS because they have been so widely used in coordination with other protocols (SRTP, SCTP, QUIC, EAP, etc.) So, it's simultaneously a full transport protocol (the original usage), an external key management protocol (OpenVPN), an embedded key management protocol (QUIC, and what's effectively a VPN protocol (SCTP over DTLS and AnyConnect VPN). Part of this can be fixed by just saying something like this and including DTLS in a few other places in the doc, but in general, the world is just complicated and so taxonomies are difficult. It would probably somewhat help to explain the common design for channel security protocols. Something like: In general, channel security protocols follow a common pattern: - A handshake protocol is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys. - A record protocol is used to encrypt traffic using keys and parameters provided by the handshake protocol. In some systems, such as IPsec, these protocols are separate: AH and ESP just assume some external source of keys and parameters; these are commonly supplied by IKEv2 but can also be supplied by some other protocol or manually configured. In other systems, these are tightly integrated, as in tcpcrypt. Some protocols can also be used in both configurations: the base TLS protocol as defined in [RFC8446] has an integrated handshake and record protocol, but TLS or DTLS can be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake can be used alone with s separate record layer, as in QUIC. S 3.2.1. You're going to want to mention DTLS-SRTP here, partly for the reasons I mentioned above but partly to help understand the situation with ZRTP. I.e., SRTP, like IPsec, just assumes that it has some external keying mechanism and DTLS and ZRTP both fill this role. S 3.3.1. I would just call this IETF QUIC, because QUICv1 is defined to use TLS. S 3.3.5. CurveCP [CurveCP] is a UDP-based transport security protocol from Daniel J. Bernstein. Unlike other security protocols, it is based entirely upon highly efficient public key algorithms. This removes many pitfalls associated with nonce reuse and key synchronization. This text is going to be confusing to people. Not to say that CurveCP is bad, and the primitives it uses *are* fast, but they're not any faster than those used by TLS, QUIC, or tcpcrypt. I think the consensus here is that it's not currently practical to have a general purpose transport protocol that doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). 3.4.3. OpenVPN OpenVPN [OpenVPN] is a commonly used protocol designed as an alternative to IPsec. A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports. OpenVPN encapsulates either IP packets or Ethernet frames within a secure tunnel and can run over UDP or TCP. It's probably worth noting that OpenVPN uses SSL/TLS for handshake, as it illustrates the pattern above. 4.1. Reliable Byte-Stream Transports The following protocols all depend upon running on a transport protocol that provides a reliable, in-order stream of bytes. This is typically TCP. Application Payload Security Protocols: o TLS Transport-Layer Security Protocols: o tcpcrypt This doesn't seem quite right, as tcpcrypt is run prior to the TCP reassembly algorithms. Packet Security Protocols: o OpenVPN Well, sort of. OpenVPN needs TCP for its key establishment phase but not its transport phase. That doesn't seem like that interesting a point to make here, as if TCP wasn't available, it could just cut over to DTLS. 5.1. Pre-Connection Interfaces Configuration interfaces are used to configure the security protocols before a handshake begins or the keys are negotiated. This presentation seems pretty hard to follow, in that it's a lot of work to figure out which in the long list of protocols doesn't have this property. Maybe a summary table would help? Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches. o Authentication Delegation: The application provides access to a separate module that will provide authentication, using EAP for example. You don't list TLS, but what about EAP-TLS? I'm not following any of the text around import. This direct/explicit distinction seems arbitrary, and weird for QUIC, because QUIC doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated. S 5.2. IKE has source address validation, no? S 5.3. o Connection Termination: The security protocol may be instructed to tear down its connection and session information. This is needed by some protocols to prevent application data truncation attacks. This seems like kind of a confusing section, I think partly because it ignores layering. The way I think of this is that we have an existing family of insecure protocols that have their own termination mechanisms (e.g., TCP FIN/RST). A security protocol that is under such a protocol (e.g., IPsec) doesn't need a secure termination mechanism because (a) the existing termination mechanism become secure and (b) it can just stop transmitting. By contrast, a security protocol that is above (TLS) or at the level of such a protocol (QUIC, tcpcrypt) needs its own secure termination mechanism, lest it be at the mercy of the transport. o Mobility Events: 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). How does this work in ESP, actually? DTLS sort of has this, in that it has a CID, but vague migration rules.
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps