Skip to main content

Last Call Review of draft-ietf-taps-minset-06

Request Review of draft-ietf-taps-minset
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-09-04
Requested 2018-08-21
Authors Michael Welzl , Stein Gjessing
I-D last updated 2018-08-26
Completed reviews Opsdir Last Call review of -10 by Linda Dunbar (diff)
Secdir Last Call review of -06 by Yaron Sheffer (diff)
Genart Last Call review of -06 by Robert Sparks (diff)
Rtgdir Telechat review of -10 by Ben Niven-Jenkins (diff)
Genart Telechat review of -08 by Robert Sparks (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-taps-minset-06-secdir-lc-sheffer-2018-08-26
Reviewed revision 06 (document currently at 11)
Result Not Ready
Completed 2018-08-26
The whole notion of TAPS is new to me, so I may be missing the point here. This
document defines a minimal set of network APIs that should be available to
applications, in order to allow multiple different transport protocols to be
used as interchangeable plug-ins with minimal or no change to applications.

However the document does not cover security, and instead refers readers to a
security protocol survey (draft-ietf-taps-transport-security).

There's a disconnect here: in many cases we want applications to be aware of
security features. For example, a typical TCP-using application should choose
whether to enable TLS encryption of the connection (or as a receiver, whether
to require encryption), and if TLS is selected, should at the very least
receive access to the authenticated address of the connection's peer. In other
words, a meaningful minimal set of APIs cannot be defined without considering
the effects and requirements of security protocols.

Put differently, the application normally treats the transport protocol and the
security protocol layered on it as one protocol. Hence the old name of TLS:
Secure Socket Layer. The application sees a single socket, not one socket for
transport and another for security. This has been the case for TCP for the last
20-odd years, and is unlikely to change any time soon.

I have not surveyed the protocols discussed in this draft, and I don't know
whether a viable transport-level security protocol exists for each of them. If
this is not the case, then I guess the industry is not yet ready for the kind
of solution proposed here.