Statement from the IETF SEC Area Directors regarding "enterprise TLS"
|From Contact||Benjamin Kaduk|
The IETF Chair
|Response Contact||Eric Rescorla
|Deadline||2019-01-18 Action Needed|
We have recently become aware of the publication of the "Middlebox Security Protocol, Part 3: Profile for enterprise network and data centre access control" by ETSI TC CYBER (https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf), which specifies what it calls "enterprise TLS" or "eTLS." We are writing to express serious concerns about the publication of this specification. This work appears to be related to the previous "mcTLS" work about which we also expressed concerns (https://datatracker.ietf.org/liaison/1538/), and our foremost concern remains the use of a name that implies the aegis of Transport Layer Security (TLS), a well-known protocol which has been developed by the IETF for over twenty years. The IETF maintains copyright and change control for all TLS specifications. Having a separate, different, protocol whose name includes "TLS" but is developed by another SDO is likely to cause confusion among developers, implementers, and users. Your liaison statement dated 11 August 2017  indicated: In response to your specific concern about the name TLS, TC CYBER does not plan to use the name TLS apart from referring to the IETF standards. Furthermore, mcTLS is the name originally given by their authors to one of the techniques TC CYBER is considering as input for its work. There are no plans to use the same term for the results of this work. We took this to mean that you had agreed to not use TLS in the name of this ETSI work product. The "Middlebox Security Protocol, Part 3" specification continues to use TLS in its protocol’s name in ways that are likely to confuse the technical community about the security properties of the proposal or of TLS. We agree with the statement in the document that what it calls "eTLS" is an "implementation variant of Transport Layer Security (TLS) version 1.3" and that unmodified TLS 1.3 clients can interoperate with MSP servers. At a protocol level, the main area of divergence from TLS 1.3 to this MSP profile is the replacement of the server’s "ephemeral" DH key with a "static" DH key, which suffices to violate the design and operational assumptions of TLS 1.3 and render this MSP profile as a qualitatively different protocol that should be named accordingly. We also note that this document proposes to implement key- and certificate-transfer functionality via HTTPS resources beginning with "/etls/keys". This usage of a static "well-known" endpoint in the site’s namespace violates BCP 190, which states that the namespace of a Web site belongs to its owner, and cannot be impinged upon by standards. RFC 5785 reserves the "/.well-known/" namespace portion to address requirements for well-known endpoints specified by protocol standards (as opposed to applications) to avoid conflicts between different metadata services and between actual site contents. We strongly recommend that you desist from using "/etls/keys" and migrate to a registered well-known location instead. We await your response on how you plan to adjust the document in order to meet your prior commitment to not use the name TLS. Regards, Benjamin Kaduk and Eric Rescorla IETF Security Area Directors  https://datatracker.ietf.org/liaison/1612/