[saag] (no subject)

[Eric Rescorla <[e-mail]>]

Document: draft-ietf-taps-transport-security-09.txt

I've reviewed this document and I do not think it should be published
in its current form.

It's probably most useful to start with the objective of this
document. Here's what the abstract says:

   This document provides a survey of commonly used or notable network
   security protocols, with a focus on how they interact and integrate
   with applications and transport protocols.  Its goal is to supplement
   efforts to define and catalog transport services by describing the
   interfaces required to add security protocols.  This survey is not
   limited to protocols developed within the scope or context of the
   IETF, and those included represent a superset of features a Transport
   Services system may need to support.  Moreover, this document defines
   a minimal set of security features that a secure transport system
   should provide.

First off, I should say that I am generally skeptical of the goal
of defining a "secure transport system", at least if we mean by
that something encompassing protocols as diverse as TLS, DTLS,
QUIC, and IPsec. Even though these are built on largely similar
cryptographic cores (in the case of TLS, DTLS, and QUIC, essentially
identical handshakes) and offer relatively similar security
record formats (AEAD-protected records), their actual notional
service interfaces are quite different. As a few examples:

- TLS depends on reliable transport services, DTLS ignores
  them, QUIC offers its own built-in reliable transport abstraction,
  and IPsec has no notion of transport at all, and relies on
  L4 transport protocols to provide any notion of application
  reliability semantics (not too dissimilar to the relationship
  between DTLS and SCTP in WebRTC).

- Despite the above, these protocols actually aren't 1-1 with
  deployment models, so for instance DTLS used to provide a VPN is
  really much more like IPsec than TLS is. So gluing DTLS
  for IoT and DTLS-VPNs together doesn't make sense.

- Although based on the same underlying authorization mechanisms,
  these protocols have different naming models (QUIC, TLS,
  and (mostly) DTLS) talking mostly in terms of domain names
  and IPsec talking mostly in terms of IP addresses (this also
  goes to whether you have a dependency on DNSSEC).

- These protocols have totally different scopes, with the application
  protocols thinking in terms of host/port quarters and IPsec thinking
  in terms of all traffic between two devices.

So, I don't think it's really possible to talk about all of these
as if they were somehow even partially interchangeable instances
of a class of protocols.


Even if we ignore this, I don't feel like the document does a very
good job of achieving this goal. A huge fraction of this document is
taken up by fairly detailed survey of the properties of each of the
relevant protocols. To the extent to which it is meaningful to do a
comparison between these protocol instances, this document seems to me
to focus largely on the wrong pieces, which is to say the
cryptographic details rather than the exposed interface
semantics. Here's a concrete example:

   IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and
   TCP port 4500.  Its primary goal is to generate keys for Security
   Associations (SAs).  An SA contains shared (cryptographic)
   information used for establishing other SAs or keying ESP; See
   Section 4.4.2.  IKEv2 first uses a Diffie-Hellman key exchange to
   generate keys for the "IKE SA", which is a set of keys used to
   encrypt further IKEv2 messages.  IKE then performs a phase of
   authentication in which both peers present blobs signed by a shared
   secret or private key that authenticates the entire IKE exchange and
   the IKE identities.  IKE then derives further sets of keys on demand,
   which together with traffic policies are referred to as the "Child
   SA".  These Child SA keys are used by ESP.

   IKEv2 negotiates which protocols are acceptable to each peer for both
   the IKE and Child SAs using "Proposals".  Each proposal specifies an
   encryption and authentication algorithm, or an AEAD algorithm, a
   Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
   algorithm.  Each peer may support multiple proposals, and the most
   preferred mutually supported proposal is chosen during the handshake.

How is any of this detail relevant? Suppose that IKEv2 were replaced
with a totally different handshake (IKEv1, DTLS, QUIC crypto), how
would the external behavior of the system be interestingly different?
>From the perspective of the consumer of such a system, the way to
think about this is that there is a handshake protocol which spits out
keys which are then fed into the IP-level packet protection machinery
(note that this is effectively what OpenVPN is, and to some extent
Wireguard, though Wireguard uses different packet protection).


Here's another example:

   Tcpcrypt extends TCP to enable opportunistic encryption between the
   two ends of a TCP connection [RFC8548].  It is a family of TCP
   encryption protocols (TEP), distinguished by key exchange algorithm.
   The use of a TEP is negotiated with a TCP option during the initial
   TCP handshake via the mechanism described by TCP Encryption
   Negotiation Option (ENO) [RFC8547].  In the case of initial session
   establishment, once a tcpcrypt TEP has been negotiated the key
   exchange occurs within the data segments of the first few packets
   exchanged after the handshake completes.  The initiator of a
   connection sends a list of supported AEAD algorithms, a random nonce,
   and an ephemeral public key share.  The responder typically chooses a
   mutually-supported AEAD algorithm and replies with this choice, its
   own nonce, and ephemeral key share.  An initial shared secret is
   derived from the ENO handshake, the tcpcrypt handshake, and the
   initial keying material resulting from the key exchange.  The traffic
   encryption keys on the initial connection are derived from the shared
   secret.  Connections can be re-keyed before the natural AEAD limit
   for a single set of traffic encryption keys is reached.

   Each tcpcrypt session is associated with a ladder of resumption IDs,
   each derived from the respective entry in a ladder of shared secrets.
   These resumption IDs can be used to negotiate a stateful resumption
   of the session in a subsequent connection, resulting in use of a new
   shared secret and traffic encryption keys without requiring a new key
   exchange.  Willingness to resume a session is signaled via the ENO
   option during the TCP handshake.  Given the length constraints
   imposed by TCP options, unlike stateless resumption mechanisms (such
   as that provided by session tickets in TLS) resumption in tcpcrypt
   requires the maintenance of state on the server, and so successful
   resumption across a pool of servers implies shared state.

How does all this detail help someone understand the role that tcpcrypt
plays in the ecosystem. Suppose, for instance, that tcpcrypt didn't
have resumption at all (not a totally absurd design decision), how would
that meaningfully affect the consumer's experience of using it in a
system?


Partly my complaint here is about presentation: a flat list of protocols
complete with a lot of detail serves to obscure the high order
architectural ideas. However, I think it's also a conceptual issue,
which is that this document focuses on the security services provided
(PFS, unilateral authentication, etc.) but that's actually a way in
which these protocols are quite similar, deriving as they mostly do
from the same few underlying cryptographic handshake shapes, with the
differences to a great extent depending on in which era the protocols
were designed (e.g., AES-CTR/HMAC versus AES-GCM), and where even
those properties are to some extent subject to negotiation. It's
also not uncommon to see features migrate between protocols, but that
doesn't change the basic architectural properties.

Instead, I think this document -- if it is to exist at all -- should
focus on the architectural position that these protocols occupy
in the stack rather than on the details of the protocol. This
would give you something that looked like this:

- Generic application-layer channel security protocols
  - TLS
  - DTLS
  - QUIC* [Plus some other stuff]
  - CurveCP (?)

- Transport-level security
  - tcpcrypt
  - MinimaLT (?)

- IP-layer VPN protocols
  - IKEv2,
  - OpenVPN
  - WireGuard
  - DTLS VPNs

- Application-bound protocols
  - DTLS-SRTP, ZRTP

And then I would have each of these start by emphasizing the common
features of these protocols and how they fit into the ecosystem, and
only briefly cover differences in the protocols to the extent to which
they were meaningfully observable (usually barely at all).

One thing I would emphasize in this context is that the protocol
differences are far less relevant from this perspective. For instance,
OpenVPN and IKEv2/IPsec use totally different cryptographic handshakes
but from an architectural perspective they fit into the same basic
box, which is part of why OpenVPN is such an easy drop-in for
IPsec-style systems.

Another example along these lines is TLS: SSLv2, SSLv3/TLS1.0-1.2, and
TLS 1.3 are really quite different protocols, but they all occupy
the same basic position in the stack and serve the same purposes,
which is why it has been (relatively) easy to just drop newer
versions of TLS into the system.

Once you do this, I think you will also need to radically rework
S 6, but I'm willing to withold judgement.


I made a number of more detailed comments on my copy, but upon
looking back, I think they mostly apply to sections I think
you should cut.