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