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

From: The IESG <[email-masked]>
Date: Fri, 04 Oct 2019 06:55:56 -0700

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
[email-masked] mailing lists by 2019-10-18. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 24 Oct 2019 13:10:10 +0000

Hi,

As Philipp asked about my reference to Christian's email and it wasn't sent
to the WG. It was sent to SAAG, and a response to a request for people to
take a look by one of the Sec Ads. 

Cheers

Magnus Westerlund

Subject: Re: [saag] Fwd: Last Call: <draft-ietf-taps-transport-security-09.txt> (A Survey of Transport Security Protocols) to Informational RFC
From: "Christian Huitema" <[email-masked]>
To: "Benjamin Kaduk" <[email-masked]>, <[email-masked]>
Date: Wed, 9 Oct 2019 04:42:42 +0200
List-Id: Security Area Advisory Group <saag.ietf.org>

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:

[email-masked] <mailto:[email-masked]>  mailing lists by 2019-10-18. 
Exceptionally, comments may be

sent to [email-masked] <mailto:[email-masked]>  instead. In either case, please 
retain the beginning of

Abstract

   should provide.

_______________________________________________

IETF-Announce mailing list

[email-masked] <mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________

saag mailing list

[email-masked] <mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/saag

_______________________________________________

saag mailing list

[email-masked] <mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/saag