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

Re: What will incentivize deployment of explicit proxies?

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Tue, 3 Dec 2013 10:53:06 +0100
Message-ID: <7fe081d8f266ddf155635af8a3550f51.squirrel@arekh.dyndns.org>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>

Le Mar 3 décembre 2013 08:37, William Chan (陈智昌) a écrit :
> Pardon me if this is obvious, but it's not immediately obvious to me what
> will cause people to use explicit proxies instead of MITM proxies? Who is
> going to deploy them? The 2 cases I can think of are:

I think browser and privacy people really need to remove their 'us vs
them' blinders and the debate will be much more constructive.

The protocol in itself is not going to change power repartition by itself.
The past proved it. Generalized TLS only resulted in generalized hostile
MITM and everyone lost (intermediaries did let TLS pass blindly as long it
was limited to clear needs like banks; they will let end-to-end http/2
encryption pass for the same needs in http/2; they won't allow it for the
streams that made them deploy TLS MITM today, it's as simple as that). So
please stop thinking about http/2 as a way for one party to force its will
on others and things will be a lot easier to design and discuss.

Once you've acknowledged that in real life the ietf and the w3c don't have
some magic powers even the UN or the USA lack today, things are a lot
easier to contemplate.

A good http/2 protocol would give visibility on the nodes that process
http traffic to everyone (web client, intermediaries, web sites). A good
http/2 protocol would give everyone the means to authenticate every other
party and communicate with it. A good http/2 protocol would give the
choice between three modes (in clear with anti-tampering signatures,
chained hops with either hop-by-hop or hop-to-end encryption with
anti-tampering signatures, end-to-end stream encryption with just enough
routing info for intermediaries to route envelopes, with possibility to
authenticate itself at every node involved).

Then, the exact mode used is negotiated between all parties (and in case
of negotiation failure the connexion fails and can be retried on another
network path later).

If browser people do their part and implement the (admittedly non-trivial)
UI to manage that, there will be a strong incentive to deploy because you
can't imagine how sick operators are of all the ways browsers screw up
http/1 by refusing to admit intermediaries exist. Browsers are by no means
pure and innocent maidens and they bear a large part of responsibility for
the current mess. Other parties are not evil monsters, by and large the
only reason they've configured MITM is because you gave them no other
choice (and then when the equipments become largely available they were
abused, they would not have been if browsers had not forced development of
stealth mode in the first place). And the correct UI is non trivial
because the real word is non-trivial, live with it reality denial will get
you nowhere.

Furthermore there will be a strong incentive for privacy people to require
from their law-maker the deployment of http/2 intermediaries because
(unlike http/1) a good http/2 protocol will enable proper communication of
terms of use between intermediaries and end-users, and clarify things
enough non-browsers get a chance to connect even in presence of
intermediaries.

And then privacy people can lobby to forbid the terms they don't like in
the same way they can lobby for anything else, and in lawful countries
whatever law is passed will be applied. Democracy strives on transparency,
not on sleight of hands (be them intermediary, web site or browser
initiated).

There is no incentive for http/2 only if you think in terms of malfeasance
and trickery, and frankly both those accusations, and the conceit you can
do anything about social contracts, are getting old fast.

-- 
Nicolas Mailhot
Received on Tuesday, 3 December 2013 09:53:43 UTC

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