With all due respect, Keith, whatever we may think of it, there are certainly people who think eavesdropping is a valid use case, and it doesn't actually serve our ability to talk about and possibly influence people who are on the fence about it if we pretend otherwise.
On Wed, Nov 21, 2018 at 8:56 AM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
Facilitating “eavesdropping “ is NEVER a valid use case.Sent from my iPhoneI would suggest being more explicit:TLS 1.3 [RFC8446] is intended to address the following use cases [cite use cases that do not include eavesdropping, and do include preventing eavesdropping and providing forward secrecy].It has come to the attention of the IETF that ETSI has published a TLS 1.3 specification which addresses a different set of use cases [cite use cases]. We wish to point out that some of the use cases addressed by RFC8446 are not addressed by ETSI. The ETSI specification should not be used in cases where addressing these use cases is required [give examples]. The IETF takes no position on whether the ETSI specification successfully addresses these use cases. However, it definitely does not address the complete set of use cases addressed in RFC 8446.Use of the TLS variant described in this ETSI specification was considered by the IETF and did not gain consensus. As such, use of this variant is not recommended by the IETF.I think publishing this as a very brief RFC would be quite appropriate.On Wed, Nov 21, 2018 at 8:05 AM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:On 11/20/18 7:44 PM, Lloyd Wood wrote:
>>> That belongs in the to be written RFC "ETSI extensions to TLS considered harmful".
>>> Of course, we may debate whether we want to publish such RFC.
>
> Perhaps a more general 'Security protocols designed by any other
> organisations considered harmful' is the way to go.
I doubt that such a direction would enhance our reputation or that of
our documents. I'd much rather see us make specific technical
arguments, e.g.
- If an IETF RFC cites TLS x.y, that citation only applies to TLS x.y as
published by IETF, not some other *TLS published by some other
organization. Just because something else is named *TLS doesn't mean
it's secure or an acceptable substitute, especially when some of them
have deliberately been made in such a way as to compromise the users'
security.
- If one party to a connection discloses the information in the
connection to a third party, whether by choice or to meet some
organizational or legal requirement, that's their business and IETF
isn't questioning that. But intercepting the traffic at the IP layer is
not a good way to implement such disclosures for several reasons - e.g.
it effectively constrains the applications to only work over particular
network segments, which harms the flexibility of the Internet as a
general-purpose communications fabric; it discourages transparency and
accountability that such record-keeping should require; etc. (It's not
the record-keeping that's being questioned; it's the very notion that
packet interception is a suitable way to accomplish that. Packet
interception is a poor architectural choice, and yes that includes
deep-inspecting firewalls and monitors.)
- For similar transparency arguments a communications protocol that is
designed to effectively appear as TLS to the endpoints and/or its users,
but which lacks the end-to-end confidentiality properties of TLS, should
be discouraged by every means available.
- The introduction of TLS variants that are designed to leak private
information seems likely to introduce yet another destructive tussle, as
privacy-conscious users try to determine whether their hosts and
applications are leaking their information, while the spooks try to
evade such detection. (Yes I'm aware that some such proposals provide
explicit information to their endpoints.)
etc.
Keith
