W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Trusting proxies (was Re: I revised the pro/contra document)

From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 25 Nov 2013 21:20:20 -0800
Message-ID: <CA+9kkMDPqds+nNmCGbo+Aa6bH_NhPSo1WCKorqqWzkOrAJ3utg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Martin writes:

> I think that your first three points or so mean that you think that
> there are three parties involved in this negotiation: user,
> intermediary and server.  You use the word "user" instead of client,
> which is telling, and probably a conscious choice.
>
> I want to work out whether this is in fact true, in the sense that the
> user is making an informed, empowered choice. I haven't been given
> information so far that would allow me to say that this is a) an
> agreed requirement (in the consensus sense), and b) possible.
>
>
I'm not sure that negotiation is the only option on the table.  If the user
and the server can each determine that a channel has an intermediary, then
they can make choices on that basis on what data to offer over the channel,
even if they have no negotiation with that intermediary.

At its very basic level, the most important point is to make it clear what
is going on.  At the moment, there is resistance to doing that because the
support costs of doing so are high; it's "cheaper" to put in something that
acts like a b2bua (for those not as SIP-terminology steeped as Martin, I
mean an interception proxy that terminates one TLS connection and starts
another, without either side aware of the proxy).

If we can make configured proxies easier and more effective for HTTP 2.0,
there's a chance things would get a bit better (using TLS to a proxy that
will then emit non-TLS, for example gets you a little something).  More
importantly, that ease of using configured proxies may also make it more
likely that other tools will get turned back on, where they are currently
turned off in the presence of the configured roots that enable interception
proxies.

None of this is a panacea, of course, but if I can at least tell when then
hop-by-hop protection I'm getting is to the proxy I intend and confirm that
I'm getting a connection to the middle and not the end, transparency about
how my use of the web is working goes up.  To me, that's a good thing, even
if I cannot negotiate what the intermediary is doing.

Sadly, I fear I'm not the UX designer you need to figure out how to show
this to an end user.  (Having spent too much time on airlines, I would have
a hub-and-spoke airline logo for one and a direct flight airline logo for
the other.  But that would just get me into trademark trouble to go with my
other, woefully poor UX design issues).  But I am convinced something is
possible here.

regards,

Ted
Received on Tuesday, 26 November 2013 05:20:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC