Liaison statement
IETF Security Area Director Concerns with McTLS

Additional information about IETF liaison relationships is available on the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2017-07-19
From Group SEC
From Contact Kathleen Moriarty
To Group ESTI-TC-CYBER
To Contacts Charles Brookson <charles@zeata.co.uk>
Alex Leadbeater <alex.leadbeater@BT.COM>
Jean-Pierre Quemard <jean-pierre.quemard@kat.bzh>
Maik Seewald <maseewal@cisco.com>
Sonia Compans <Sonia.Compans@etsi.org>
Cc The IETF Chair <chair@ietf.org>
Eric Rescorla <ekr@rtfm.com>
Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Response Contact Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Eric Rescorla <ekr@rtfm.com>
Purpose For action
Deadline 2017-10-06 Action Needed
Attachments (None)
Body 
We have recently become aware of ETSI's work on “Multi-Context Transport Layer Security
(mcTLS)” and are writing to express our concerns about this effort.
Our foremost concern is the use of the name 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 TLS specifications. Having a separate, different, protocol
named "TLS" but developed by another SDO is a recipe for confusion among developers,
implementers, and users alike.

Beyond the confusion related to the origin of the specification, there are differences in
the design goals. The IETF remains strongly committed to fostering end-to-end security[1][2]
[3], and the properties of TLS enable that for key IETF protocols. We believe the ETSI work
to proceed from a different design goal: to enable third-party monitoring. Because
applications using TLS expect its end-to-end security properties, the re-use of the name
will create misunderstandings. We therefore formally request that ETSI alter the name of its
work enabling third-party monitoring so that implementors, users, and governments are not
confused about its properties or the properties of TLS.

We also wish to express our technical reservations with the mcTLS approach. Protocols and
applications which use TLS for security depend upon TLS's end-to-end security properties and
will have very different and weaker security properties when using a multi-party transport
security protocol such as mcTLS. These unexpected behaviors create a serious risk to the
security of these protocols if TLS is simply replaced with mcTLS. As ETSI takes on this
work, we suggest you consider these design elements and the security of the system as a
whole, rather than attempting to design a drop-in replacement for TLS.

[1] RFC1984 https://tools.ietf.org/html/rfc1984
[2] RFC2804 https://tools.ietf.org/html/rfc2804
[3] RFC7258 https://tools.ietf.org/html/rfc7258

Regards,
Kathleen Moriarty and Eric Rescorla
IETF Security Area Directors