Re: [saag] Fwd: Last Call: <draft-ietf-taps-transport-security-09.txt> (A Survey of Transport Security Protocols) to Informational RFC

[Christian Huitema <[e-mail]>]

Please disregard my previous message. I got my email very confused, and
reviewed a TSVWG draft instead of draft-ietf-taps-transport-security-09.txt.

My assessment of draft-ietf-taps-transport-security-09.txt would be
pretty close to EKR's review.

The TAPS architecture assumes some kind of "protocol agnostic" API.
Applications would specify the transport features that they want using
an abstract definition, and the TAPS implementation would then
automatically select among the implementations available on the
platform. In the target scenario, the application could specify
something like "encrypted connection, authenticating the server, and
providing a reliable stream". The platform could then select "SCTP over
DTLS", or "TLS over TCP", or "QUIC". I personally have serious doubts
about the viability of such scenarios. Protocols like QUIC or TLS are
implemented in application space and shipped with the application code,
so an application can guarantee that its protocol of choice is available
without going through a selection API. But the IETF did charter the TAPS
working group and that's what it does.

Based on the TAPS charter, the authors go on to inventory a set of
security protocols and attempt to characterize them by drawing a set of
properties. I agree with EKR's observation that the proposed
classification feels somewhat arbitrary. Can we really compare IPSEC and
TLS by checking whether they support pre-shared keys or source
validation? Can we do that without analyzing the type of identities
supported by these protocols? Obviously, much of the security properties
are function of something else that API features. Can we compare TLS 1.0
negotiating RC4 to TLS 1.3 negotiating AES128-GCM? If we really dream of
protocol selection APIs as envisaged in the TAPS charter, should it
expose available algorithms as well as stated features? Does it matter
whether there is a formal proof available for the protocol design?

In fact, this document begs another question. It is a product of a
transport area working group trying to compare properties of protocols
defined in the security area. It is applying the same methodology to
comparing security protocols that it used for comparing UDP, TCP and
SCTP. Clearly, some of the authors do have security expertise, but
that's the working group as a whole does not. Should the transport area
write down assessments of security protocols?

-- Christian Huitema

On 10/8/2019 3:04 PM, Christian Huitema wrote:
>
> As the draft mentions:
>
>    The use of transport layer authentication and encryption exposes a
>    tussle between middlebox vendors, operators, applications developers
>    and users
>
> Much of the draft content goes on explaining the middlebox vendors'
> view of that tussle. As such, the draft is not terribly helpful...
>
> On 10/6/2019 9:12 AM, Benjamin Kaduk wrote:
>> I think several folks have taken an early look at this one; now would be a
>> great time to take a second look.
>>
>> -Ben
>>
>> On Fri, Oct 04, 2019 at 06:55:56AM -0700, The IESG wrote:
>>> The IESG has received a request from the Transport Services WG (taps) to
>>> consider the following document: - 'A Survey of Transport Security Protocols'
>>>   <draft-ietf-taps-transport-security-09.txt> as Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits final
>>> comments on this action. Please send substantive comments to the
>>> [e-mail] mailing lists by 2019-10-18. Exceptionally, comments may be
>>> sent to [e-mail] instead. In either case, please retain the beginning of
>>> the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>    This document provides a survey of commonly used or notable network
>>>    security protocols, with a focus on how they interact and integrate
>>>    with applications and transport protocols.  Its goal is to supplement
>>>    efforts to define and catalog transport services by describing the
>>>    interfaces required to add security protocols.  This survey is not
>>>    limited to protocols developed within the scope or context of the
>>>    IETF, and those included represent a superset of features a Transport
>>>    Services system may need to support.  Moreover, this document defines
>>>    a minimal set of security features that a secure transport system
>>>    should provide.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/
>>>
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag