Re: [secdir] [Taps] Secdir last call review of draft-ietf-taps-minset-06

["Aaron Falk" <[e-mail]>]

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 <[e-mail]> 
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/taps
>>