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

[Keith Moore <[e-mail]>]

I’m aware of course that such people exist.  But I think they have the burden of explaining for instance (a) even if there are legitimate reasons for third parties to access traffic, why having access to the physical media confers such legitimacy; and (b) why such access should not be engineered in such a way as to provide transparency and accountability.  

I also think it’s quite clear that some people who believe that there are legitimate use cases for eavesdropping are in fact the enemies of a free society and we do ourselves no credit to pretend otherwise.

Sent from my iPhone

> On Nov 21, 2018, at 9:01 AM, Ted Lemon <[e-mail]> 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.
> 
>> 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
>>>> 
>>>>