Liaison statement
Statement from the IETF SEC Area Directors regarding "enterprise TLS"

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 [0]
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

[0] https://datatracker.ietf.org/liaison/1612/