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
--- Begin Message ---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 [email protected] <mailto:[email protected]> mailing lists by 2019-10-18. Exceptionally, comments may be sent to [email protected] <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ saag mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/saag_______________________________________________ saag mailing list [email protected] https://www.ietf.org/mailman/listinfo/saag
--- End Message ---
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
