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

Re: Explicit proxy options and defaults

From: Yoav Nir <synp71@live.com>
Date: Mon, 9 Dec 2013 00:19:17 +0200
Message-ID: <BLU0-SMTP203F52C82AD062A7BD48821B1D00@phx.gbl>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 8/12/13 10:39 PM, Stephen Farrell wrote:
>
> On 12/07/2013 11:33 PM, Yoav Nir wrote:
>> Hi, Stephen
>>
>> The choice between (2) and (3) is with the proxy.
> Maybe I wasn't being clear. Let me try again:
>
> If there is a reasonable (2) then I'm asking that both (2) and
> (3) be supported but for (3) to be the default.
>
> The explicit proxy should be just one of the players who
> can say no in this game.
>
>> How it communicates
>> that choice to the client is up to the group, but in any case doesn't
>> seem to matter much security-wise. Adding authentication and encryption
>> to the connection to the proxy regardless of whether it decrypts or not
>> is also a good thing.
>>
>> Having the proxy choose (2) should not be seen as an alternative to (3).
>> (3) doesn't allow the proxy to do anything except maybe domain name
>> filtering.
> Precisely. And that (3) is the currently specified semantics for
> https via a proxy so needs to be the default.

What I'm missing in this discussion is what default means. The client 
connects to the explicit proxy. It can now either send a CONNECT (or is 
the new notation ":connect"?) or a "GET https://something.example.com". 
One will work, the other won't, depending on the proxy. I don't see 
where defaults come into play.
> (2) is the new thing that you want to introduce where the proxy
> gets to decrypt.
>
>> So (2) is an alternative to the MitM proxies that require
>> installing a CA certificate and signing phony certificates. Killing off
>> those practices is a win IMO.
> Yes, one can argue that introducing (2) might help kill off the
> alternative of MITMing TLS. But equally doing away with (3) which
> we have now means weakening https:// URI security in a real sense.
>

Whereas for servers people can argue that TLS is a small part of the 
cost, for a proxy, decrypting and re-encrypting is a huge part. The 
bandwidth that a proxy can support is likely 10 times greater for 
CONNECT vs GET. People will never do the GET unless there is a very good 
reason that justifies the cost, and if such a reason exists (filtering, 
caching), they won't agree to CONNECT at all.

Yoav




Received on Sunday, 8 December 2013 22:19:38 UTC

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