Explicit proxy options and defaults

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 Saturday, 7 December 2013 18:38:24 UTC