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

Re: new version trusted-proxy20 draft

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Wed, 19 Feb 2014 10:30:01 -0500
Message-ID: <CANmPAYEgC8TdfxpXzg9DkdqYCVxDkf=RRfYtx+wC=zqVUNVv-Q@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Paul Hoffman <paul.hoffman@gmail.com>, 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>
My two takeaways from Zurich on trusted proxy were as follows:

1) We need to look at use cases of trusted proxy and seek alternative
technologies. I've attempted to start this process on another thread, which
I believe shows current (and future) alternatives are partial solutions
that we can conclude are inadequate overall in delivering the functionality
and performance users/admins/service providers demand.
2) Until someone proposes a UI for opt-in and opt-out of trusted proxy that
is both user friendly and does not make MITM attacks (rogue trusted
proxies) easier to execute, then the debate on this topic is at a
standstill. I am working on ideas in this area but it will take more than
just a few weeks. It would be really great if others got involved.

Salvatore's draft has some really good ideas but it does not attempt to
address #2 above, which most agreed was the sticking point on trusted
proxy, which we distinguish from "secure proxy" by the fact that a trusted
proxy can see https-schemed traffic in plaintext.

Peter


On Tue, Feb 18, 2014 at 11:54 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> On Tue, Feb 18, 2014 at 8:18 PM, Paul Hoffman <paul.hoffman@gmail.com>
> wrote:
> > On Tue, Feb 18, 2014 at 6:02 PM, 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. I don't really see the value for end users in
> >> standardizing any mechanism for doing this. Is there any?
> >
> >
> > This still comes back to the theory that a trusted, explicit firewall,
> such
> > as a corporate firewall, should be able to snoop on all traffic leaving
> the
> > protected network. There are plenty of good reasons to do this, and
> plenty
> > of people who disagree that there are any possible reasons.
>
> Good point. This is a controversial topic that we're unlikely to see
> consensus on in the near future. Let me ask another question. Is there
> a user agent that plans on supporting this proposal? At the Zurich
> interim, IIRC, Patrick (Firefox), Rob (IE/WinInet), and I (Chromium)
> all said we do not support this. If that's in error, please speak up.
> Otherwise, if no user agent plans on supporting this, I don't see the
> value of standardizing this.
>
>
Received on Wednesday, 19 February 2014 15:30:28 UTC

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