My $0.02: I don't think it is too early for a SecDir review. --aaron
(TAPS wg chair)
On 27 Aug 2018, at 16:00, Benjamin Kaduk wrote:
On Mon, Aug 27, 2018 at 08:53:16AM -0700, Tommy Pauly wrote:
Hi Yaron,
This minimal set is a description of the surface that any generic API
must have to cover the common *transport* features of protocols only.
This document is not meant in itself to describe an API that
applications use directly, but instead describe the distilled feature
set from transport services (such as reliable/unreliable sending,
etc). To that end, it essentially describes what you need to be able
to use basic things like TCP, UDP, etc. Even without security
considered, this distillation is a non-trivial task, thus it required
this document.
The security document that is referenced
(draft-ietf-taps-transport-security) provides a similar survey and
distillation for how transport security interfaces add more surface
to control and interact with handshake and record layers used on top
of/in conjunction with the base transport.
FWIW, I think that draft-ietf-taps-transport-security would benefit
from
some more attention from the security (is it ready enough to ask for
an
early secdir review?). I looked at bits of the -01, and though the
-02 is
improved in some ways, I think there are still some incorrect
statements
present about some of the protocols in question, etc.. Anyone from
secdir
interested?
-Ben
The set of documents that actually describe the API surface that we
want applications to use (draft-ietf-taps-arch, draft-ietf-taps-api,
draft-ietf-taps-interface, draft-ietf-taps-impl) does indeed provide
a unified abstraction for a secure transport connection. However,
this surface depends upon both the distillation from
draft-ietf-taps-minset and draft-ietf-taps-transport-security. There
is no intention of promoting insecure connections for applications.
Thanks,
Tommy
On Aug 26, 2018, at 10:03 PM, Yaron Sheffer <[email protected]>
wrote:
Reviewer: Yaron Sheffer
Review result: Not Ready
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.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
