Re: [Secdispatch] draft-campling-ech-deployment-considerations (was: Request for a slot at the Secdispatch IETF 113) Session

[Toerless Eckert <[e-mail]>]

I find subject draft to be very useful in pointing out the challenges ECH
introduces to security operations that can not simply be given up, so
it would really be great if the IETF would put an effort into finding
adequate solutions for this issue.

On Tue, Mar 22, 2022 at 01:17:11PM +1100, Mark Nottingham wrote:
> 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.

I think it is purely a matter of feasibility. With all the different OSs and
client software, it is practically impossible for entities responsible for
security to always ensure that the endpoint software includes all necessary
security element. Having been working for companies who where upsold into
MDM endpoint software for at least a decade, i know how many constraints this
has, and what pain it creates. Foremost also, how intrusive it is to the
users. And i would be surprised if you find a lot of enterprise worker
with sufficient insight into the matter that would disagree. Aka: user privacy
can IMHO not be maintained anymore when current state of the art on-endpoint
software is used (MDM).

On the other hand, i fully agree with the sentinement that simply letting
the server certificate stay in the clear is also not a good solution for user
privacy. IMHO it is at best a workaround that should be possible to enable until the IETF
has standardized a better solution.

Aka: IMHO what we need is a way for connection setup to be performed in a way
that a client-device trusted man-in-the-middle can validate the server
certificate and client credentials for the trusted man-in-the-middle.
But nothing else, especially not the payload. 

My typical workflow btw would be client devices in the Jones' family home
where one would need to enter on each client device merely credentials for
the families home gateway, and that home gateway would then be able to
have a permitted matrix of which client (aka: user) would be able  to
have communications with which internet service (by certificate/dns-patterns),
but without that home gateway being able to exmine the conversation.

And of course, ideally, on the server there should be zero or minimum
change to the protocols needed to be supported to enable this. And of course,
any untrusted MitM must not be able to oberve server certificate.

Cheers
    Toerless