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
