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

Re: new version trusted-proxy20 draft

From: 陈智昌 <willchan@chromium.org>
Date: Tue, 18 Feb 2014 23:37:38 -0800
Message-ID: <CAA4WUYj3Fix-7Nj1Afp=ME2LoTdRO45zjTNLsNGu-82fAk+mXg@mail.gmail.com>
To: Thomas Fossati <TFossati@velocix.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Salvatore Loreto <salvatore.loreto@ericsson.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>
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. 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.

>>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 07:38:10 UTC

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