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

On Nov 26, 2013, at 7:20 AM, Ted Hardie <ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>> wrote:

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.

yes
The first step is to let the client (I am not going in user consciousness issue at moment)  and the server become aware of the existence of an intermediary in between, so that the client and the server can decide how to behave (i.e. what content request/provide)
but they should be also able to opt out (i.e. using a mechanism like connect or a similar one) if they really do not want the proxy stay in between.




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,

that is definitely an area we have to work on

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.

that is the main point, we have to improve the situation compared to what we have at moment.


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.

a big part of all the challenge will be on the UX designer.
I also think it would be possible to come up with something really great

/Sal


regards,

Ted