Re: [Patient] [EXT] Re: Internet Draft posted as requested -

[Brian Witten <[e-mail]>]

Hi Paul,


Thanks!  I'm not against true end2end client-auth.  That would help the server know for sure to whom they are talking, including both an endpoint that couldn't be impersonated, and the middlebox which the client wants helping with security.  Sending data "back" into the network just often has a too-ugly bandwidth cost.  Doing things in-flow is far better from a bandwidth perspective, and I'm happy to make these middleboxes (currently impersonating) more explicitly accountable for their presence in the communications...


I hope that helps!  Thanks Again!!


Brian


________________________________
From: Paul Wouters <[e-mail]>
Sent: Thursday, December 14, 2017 3:10:53 PM
To: Brian Witten
Cc: [e-mail]; [e-mail]
Subject: [EXT] Re: [Patient] Internet Draft posted as requested -

On Thu, 14 Dec 2017, Brian Witten wrote:

> As a side comment, I’d also note the use of pejorative phrasing.  “argues for the mitm attacks on https,” … It seems that you’re calling “network based blocking of malicious webpages” an “attack” when the blocking is actually blocking the server's _attack_ against the client.  Where I choose to have a network proxy protect from evil on the net, I don’t consider that proxy to be attacking me.  I consider that proxy to be protecting me, and many organizations manage keys accordingly.  We see more and more people needing network help in protecting themselves from such attacks, as laid out in (1) through (5) above.  I look forward to your feedback there.

Some call it that because you are actively trying to circumvent protection
that https offers.

If you let the client decrypt the data and then sent that data (encrypted)
to the network agent, no one would call it mitm attack.

But your proposal is to give private (session) keys from endpoint to
the network agent, basically giving it the full power to impersonate
the endpoint. That is a dangerous and needlessly insecure compromise.

Similarly, an email message can be received over TLS, and then forwarded
to the network agent for scanning without giving the network agent the
key material to sit in between network agent and remote mail server.

Paul