Re: new version trusted-proxy20 draft


On Feb 20, 2014, at 2:40 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> On Wed, Feb 19, 2014 at 1:17 PM, Salvatore Loreto
> <salvatore.loreto@ericsson.com> wrote:
>> 
>> On Feb 19, 2014, at 7:09 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:
>> 
>>> Yeah, I'd like to see the "secure proxy" proposal separated out from
>>> the "trusted proxy" proposal. Let's move forward on the "secure proxy"
>>> one. I think the "trusted proxy" proposal is more complicated.
>> 
>> I agree
>> and the draft is really proposing a "secure proxy" solution
>> in line with your definition of "secure proxy"
>> 
>> indeed we are only proposing the possibility for the proxy to ask consent
>> to opt in for http:// resources traffic
> 
> Let's be clear, these are two different things. There's "secure proxy"
> which is securing the connection between the proxy and the client. I'm
> supportive of standardizing this. Then there's this opting into
> allowing http:// resources to be sniffed by signaling it via ALPN.
> What's the value proposition here? Why not issue the request to the
> proxy if you want to let it see it, just like we do for configured
> HTTP proxies?

The value proposition here is that the user-agent does not have to be configured to use the proxy, but is still able to take advantage of the benefits it can provide.

Think about the situation where you're on vacation in a remote area with limited network resources. You wish to download an application.  The network you're on has a caching proxy with the application cached.  You are able to download the application faster, without tying up the resources in the remote location.  That's the value proposition.

I have also tried to explain those benefit here [1]

And yes, the response is "well why not just configure the user-agent to use the caching proxy?" Technically, this suggestion is completely correct, but from a practical standpoint it makes no sense at all: users will not manually configure address http proxies.  
What we're proposing here is providing better security for the user-agent (all content encrypted), preserving existing functionality (caching proxies, virus scanning proxies, etc), and providing a mechanism where the user is completely aware of any entity in the middle of their normal "http://" traffic.  

Https traffic, is still there, providing private end to end encryption.

br
Sal

[1]http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0602.html

Received on Monday, 24 February 2014 19:58:12 UTC