Re: Trusted proxy UI strawman

Hiya,

On 16/06/14 04:01, bizzbyster@gmail.com wrote:
> 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.

I think the word "user" in the above is conflating people (with a
browser), content authors and n/w operators, at least. I (as a
user visiting web sites) do not "want this," nor do I as a content
author, nor do I as a (very very tiny:-) web site admin. And I
definitely do not "want this" for my calendar nor IMAP etc.

So I don't agree that borking TLS is the most straightforward way
to do something that I want, for at least 3 or 4 definitions of
me as a user. And I'm pretty sure that I'm not at all alone in that.
(But wasn't a lot of the above said already on this list?)

> "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.

Mostly I have in mind not borking TLS;-)

I'm sorry to seem so negative here, but when there are such
conflicting requirements, I guess that's gonna be the case.
In my defence, I think I can fairly claim that "don't bork
TLS" is actually a positive statement overall.

Cheers,
S.


> 
> 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 10:35:22 UTC