W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: new version trusted-proxy20 draft

From: Salvatore Loreto <salvatore.loreto@ericsson.com>
Date: Wed, 19 Feb 2014 21:04:28 +0000
To: William Chan (陈智昌) <willchan@chromium.org>
CC: Thomas Fossati <TFossati@velocix.com>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>, "draft-loreto-httpbis-trusted-proxy20@tools.ietf.org" <draft-loreto-httpbis-trusted-proxy20@tools.ietf.org>, GUS BOURG <gb3635@att.com>
Message-ID: <125788B0-0334-4F74-8D15-6F15B7CDE333@ericsson.com>

On Feb 19, 2014, at 8:37 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> On Tue, Feb 18, 2014 at 10:57 PM, Thomas Fossati <TFossati@velocix.com> wrote:
>> On 19/02/2014 02:02, "William Chan (陈智昌)" <willchan@chromium.org> wrote:
>>> And furthermore, I should add that I don't really think it's in the
>>> users' interests to have an intermediary be able to snoop listen in on
>>> all their https traffic.
>> 
>> It’s not the https traffic that would be snooped, but the http traffic
>> carried over HTTP/2.0 + TLS
> 
> If this is the case, I'm less concerned. I misinterpreted the
> "trusted" part of the proxy proposal as implying that the proxy would
> be trusted to snoop on https traffic, as that's how we've previously
> used the term. If this proxy has no more privilege than any other
> forward proxy, that sounds mostly fine to me. That said, I still agree
> with Patrick that there doesn't seem any reason to allow
> differentiation of http vs https traffic. If the user agent and origin
> agree to put http traffic over a user-agent<=>origin TLS connection,
> then they should be allowed to do so without having to mark it via
> ALPN. If the user agent really wanted to opt into letting the proxy
> server see the http request, it can issue the http request to the
> proxy and let the proxy fetch it from the origin, just like we do for
> all other HTTP forward proxies today.
> 
> I recommend rephrasing this as a secure proxy proposal, rather than a
> trusted proxy proposal.

thanks for the suggestion
the terminology is always a slippery field, let's consolidate it

I will change to "secure proxy" in the next version

> Securing the user-agent<=>proxy connection
> sounds like a fine endeavor to me (indeed, Chromium already supports
> this behavior), and I'd like to see it standardized.

+1

> 
>> 
>>> I don't really see the value for end users in
>>> standardizing any mechanism for doing this.
>> 
>> E.g. getting lower latencies on mobile networks (due to improved caching
>> at the edge).
>> 

Received on Wednesday, 19 February 2014 21:04:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC