Re: Explicit proxy options and defaults

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.

(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.

S.

> 
> Yoav
> 
> On 7/12/13 8:37 PM, Stephen Farrell wrote:
>> So Tim raised an important point about options for proxies and
>> defaults that I think maybe warrants its own thread.
>>
>> Let's assume for a minute the WG manage to design an acceptable
>> solution that allows for Yoav's corporate proxy. That means
>> that Yoav would have one of two things going on when he uses
>> TLS from a web browser: a direct TLS connection or a connection
>> via an explicit proxy that decrypts and re-encrypts.
>>
>> But, don't we really need three options: 1) direct, 2) via
>> explicit TLS proxy that decrypts (as above) and 3) via explicit
>> TLS proxy and CONNECT (where the TLS proxy doesn't decrypt and
>> there is an e2e TLS session providing confidentiality).
>>
>> It seems to me that (1) and (3) match the currently deployed
>> web and so need to be maintained as the respective defaults for
>> when there is no proxy and when there is an explicit proxy.
>> (And I like (3) since its a security improvement over today's
>> web for proxy auth.)
>>
>> And if an acceptable solution for (2) is found, that has to be
>> the non-default or else we're changing the semantics of HTTP.
>> In other words, (3) has to be the default for explicit proxies
>> since that's semantically the same as what we do today.
>>
>> Is this on the right track, or would (3) as the default for
>> explicit proxies mean that the incentives for explicit proxies
>> decrease again to the point where they're not considered
>> worthwhile by those who'd implement them?
>>
>> FWIW, its seems to me (wearing no hats) that "(2) without (3)"
>> would represent an overall worsening in the security of http/tls
>> whereas a "(2) and (3) with (3) as default" outcome could be
>> described as neutral or positive, depending on how (2) worked
>> and on what's likely to be implemented and deployed.
>>
>> Regards,
>> S.
>>
>>
> 
>

Received on Sunday, 8 December 2013 20:40:27 UTC