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
