Re: Explicit proxy options and defaults

Hi, Stephen

The choice between (2) and (3) is with the proxy. 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. 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.

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