Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session

[Mark Nottingham <[e-mail]>]

I'm not going to be at SECDISPATCH, so I'll make my comments here.

First, a general comment. Andrew, you seem to be forming a habit of relying on 8890 to get air time for your arguments. That RFC's focus is on encouraging the IETF community to consider the impacts of its actions elsewhere. The only place it privileges those already active here is when it talks about civil society organisations' ability to act as a channel for engaging the broader Internet community. I don't believe you're acting in that capacity here. 

I.e., your arguments should stand on their own -- invoking 8890 doesn't reinforce them.

Now, regarding the draft -- draft-campling-ech-deployment-considerations seems to assume that the *only* viable way to scan for viruses, impose parental controls, or control access to resources is by having a network element impose it without coordination. Your draft supports this by noting that transparent proxies are used because they're easier to administer than on-endpoint software -- a viewpoint which privileges administrator convenience and cost over user safety,  and ignores other options.

The underlying problem is that such "transparent proxy" services are unauthenticated -- they rely on the user understanding that the network is going to perform these services, and accepting their imposition. They're also disproportionate, giving complete access to all data flows and capabilities on the connection.

Performing these tasks in this fashion allows not only legitimate authorities to impose them, but also illegitimate attackers. As such, they're inappropriate for deployment on the Internet, and that's why we're seeing efforts like ECH -- use of this data and the associated control channel without explicit user authorisation is not "permissionless innovation" (as your draft states), it's an open door to abuse. Put bluntly, you (as a network operator) don't have a right to "innovate" with my data (as a user) -- especially without my permission.

This doesn't reduce the urgency of meeting those goals for some users, but it does mean that they need to be met without endangering security and privacy for all users on the Internet, even if that has historically been the path of least resistance.

It also doesn't mean that the path forward will be easy. What's required is a discussion and implementation of interfaces for offloading these functions from operating systems, applications, and IoT devices -- potentially to somewhere else on the network -- in a way that maintains users' autonomy, privacy, and security, and in a proportional way (i.e., only as much access to data as required to fulfil the task). That is difficult not only because of the inherent user interface subtleties and potential for abuse/hijacking, but also because there is little current coordination or convergence at that layer.

The IETF has a very clear responsibility to assure that the protocols it ships are secure -- hence, ECH. It *could* have a role to play in responsibly offloading these functions, especially where the work intersects protocol design. There is also other work to be done that's squarely outside our scope. I'd suggest that you and your co-authors focus on assisting those positive, forward-looking efforts rather than trying to stop ECH deployment.

Cheers,


> On 17 Mar 2022, at 7:38 pm, Andrew Campling <[e-mail]> wrote:
> 
> Hi David
> Thank you for your interest in the draft.  You’re right to highlight the benefit of privacy but, as you will see when you read the draft, we highlight a range of issues that can reasonably be considered as being in the interest of end users such as security, cost and complexity.
> 
> Focusing specifically on privacy, it is of course more complex than encryption.  For example, as noted in the draft, by removing an indicator of compromise (the SNI data), a user may be at greater risk of attack from malicious content or simply by surveillance by badly behaved client software.  
> 
> RFC 8890 highlights the importance of multistakeholder input in order to understand the potential trade-offs between competing factors that may impact end users.  This is an instance where such engagement would be beneficial as it will no doubt highlight other considerations to take into account.
> 
> As you conclude, let’s discuss it at Secdispatch but I believe that debate will be more useful if we avoid using such a narrow interpretation of end users' interests.
> 
> Andrew
>  
> From: David Schinazi <[e-mail]>
> Sent: Thursday, March 17, 2022 1:01 am
> To: Andrew Campling <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session
>  
> Hi Andrew,
> 
> (I'm writing as an IAB member, but not representing the IAB)
> 
> Your understanding of IAB document RFC 8890 is incorrect. Encrypting the TLS Client Hello is performed to protect end users. In particular, it is an example of Section 4.2 "Creating User-Focused Systems" as it brings control over information sharing closer to the end users. Additionally, ECH was the product of Section 4.3 "Identifying Negative End-User Impact" as we have seen abuse of user information caused by networks observing the SNI. That section additionally references RFCs 7258 and 7624 which clearly lay out the dangers of cleartext information and the user benefit of encryption. If you'd like more information on the IAB's position on this topic, we also released the following statement: <https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>.
> 
> You're welcome to raise your concerns about ECH, but they are in the opposite of the spirit of RFC 8890. Let's discuss your draft at secdispatch, but I can't imagine it progressing with such a clear misunderstanding of RFC 8890.
> 
> Thanks,
> David
> 
> On Wed, Mar 16, 2022 at 9:15 AM Andrew Campling <[e-mail]> wrote:
> I would like to request some time to dispatch draft-campling-ech-deployment-considerations at IETF 113.  The draft is intended to inject additional detail about deployment considerations relating to Encrypted Client Hello by including observations on current use cases for SNI data in a variety of contexts.  In the spirit of RFC 8890, we believe that end-user needs to be taken into account in protocol development and we hope that this document is one small step in that process. 
>  
>  
> Andrew
>  
>  
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch

--
Mark Nottingham   https://www.mnot.net/