Re: new version trusted-proxy20 draft

On Feb 24, 2014, at 10:10 PM, William Chan (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>>
 wrote:


On Feb 24, 2014 11:57 AM, "Salvatore Loreto" <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
>
>
> On Feb 20, 2014, at 2:40 AM, William Chan (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:
>
> > On Wed, Feb 19, 2014 at 1:17 PM, Salvatore Loreto
> > <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
> >>
> >> On Feb 19, 2014, at 7:09 PM, William Chan (陈智昌) <willchan@chromium.org<mailto: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.

Oic, I had assumed we were only talking about configured proxies. This makes more sense now, but I still disagree with it because it weakens opportunistic encryption (which I also don't support but I don't see why we should weaken that).

Can you clarify whether the "secure" proxy (TLS to the proxy) part of your proposal is also for transparent proxies? I don't see how that would be possible, so I assume at least that part is for a configured proxy.

let me start clarifying my previous answer, when I said
"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."

I meant "the user-agent does not have to be *manually configured* to use the proxy"
the proposal DOES NOT propose a transparent proxy solution

we are proposing that the proxy always advertises itself and its presence to the user
the user is fully in control, she/he has to provide or deny consent to use the proxy…
if the user provides consent to the proxy then and only then the proxy becomes configured within the user agent

so the answer is YES we are talking about configured proxy

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