Subject: Re: [Taps] Review of draft-ietf-taps-transport-security-10

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Mar 2020 12:43:49 +0000

HI Ekr,

I have looked at the changes in -11 of the draft and they appear to resolve 
your comments below. I would appreciate feedback if you concur with my 
assessment. I will however in the meantime go forward and schedule this 
document for IESG evaluation. It will at the earliest be on the IESG agenda on 
the 9th of April.

Cheers

Magnus Westerlund

From: Eric Rescorla <[email-masked]>
Sent: den 1 december 2019 01:42
To: [email-masked]; [email-masked]
Subject: Review of draft-ietf-taps-transport-security-10

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.