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