Re: new version trusted-proxy20 draft

On Feb 24, 2014 11:57 AM, "Salvatore Loreto" <salvatore.loreto@ericsson.com>
wrote:
>
>
> 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.

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.

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