Re: [IAB] IAB report to the community for IETF 103

[Ted Lemon <[e-mail]>]

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 <[e-mail]>
wrote:

> Facilitating “eavesdropping “ is NEVER a valid use case.
>
> Sent from my iPhone
>
> On Nov 21, 2018, at 8:47 AM, Ted Lemon <[e-mail]> 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 <[e-mail]>
> 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
>>
>>
>>