Ted Lemon <mellon@xxxxxxxxx> wrote:
> 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.
Yes, some of them think of themselves as providing an auditing function.
It would be good to know which argument is being used in each case.
> 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 iPhone
> On Nov 21, 2018, at 8:47 AM, Ted Lemon <mellon@xxxxxxxxx> wrote:
> I 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
> ----------------------------------------------------
> Alternatives:
> ----------------------------------------------------
