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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 26 Aug 2018 22:03:45 -0700

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.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 27 Aug 2018 08:53:16 -0700

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.

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-masked]> wrote:
> 
> Reviewer: Yaron Sheffer
> Review result: Not Ready
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Aug 2018 15:00:19 -0500

> 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 intera…

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

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 27 Aug 2018 16:01:47 -0400

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:

>> 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.
>
>> 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
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Aug 2018 23:39:31 -0700

Thank you Tommy for setting me straight on this. I appreciate the 
additional context.

I looked at draft-ietf-taps-interface and it does seem to cover secure 
connection establishment well enough.

With that in mind, I am OK with the Security Considerations in 
draft-ietf-taps-minset.

Regards,
	Yaron