Re: Trusted proxy UI strawman

Hi Stephen,

Our users want this so we are building it -- and we prefer to provide them with a mechanism to opt in and out on a per site basis as well as solve the problem of transitive trust introduced by standard MITM proxies. While changes to the TLS layer are not required, it is the most straightforward way to provide optimization for HTTPS web sites for a service provider that has already deployed web acceleration via proxies for HTTP-schemed web sites. Ideally the protocol changes we make to our proxy and our web browser, including users on commercial airlines like JetBlue and United, will be standardized so that our users will get optimization when using other browsers and also when they are using our browser when communicating with other proxies.

"If HTTP needs a proxy solution,please aim to develop an HTTP solution and do not affect the many other protocols and applications within and beyond the IETF that depend on TLS and that do not need an MITM."

What did you have in mind? I'm really interested in alternatives that do not involve modifying the TLS layer.

Thanks,

Peter


On Jun 15, 2014, at 3:48 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> 
> On 15/06/14 20:34, bizzbyster@gmail.com wrote:
>> The whole idea of this proposal is to make it no different than
>> today's MITM ...
> 
> I'm not sure that I'm exactly clear on what's proposed but in any case
> the above is not at all attractive. I thought we had already had the
> discussion here that ended up concluding that MITMing TLS is not the
> way to try tackle an HTTP problem. The MITMing-TLS approach has been
> proposed and rejected many times. If HTTP needs a proxy solution,
> please aim to develop an HTTP solution and do not affect the many other
> protocols and applications within and beyond the IETF that depend on
> TLS and that do not need an MITM. And that might not have a user or
> browser or equivalent.
> 
> I mean we could repeat all that debate, but it seems better not to do
> that to me at least.
> 
> S.

Received on Monday, 16 June 2014 03:02:18 UTC