RE: Explicit proxy options and defaults

On Mon, 9 Dec 2013 14:11:16 -0800, Ted Hardie wrote:
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.
 So, I think we largely agree on this, but that the way you have stated makes it hard to tease out.  Let me test my understanding with a slight reformulation:
A proxy can be configured to either act on a flow or to allow a flow to pass.  If it is configured to allow a flow to pass, it will support CONNECT for that flow (for example, an enterprise might require all flows pass through a proxy, but permit CONNECT for targets within its own administrative domain).  If it is configure to act, it must decrypt any encrypted flow before acting, then re-encrypt the result after the action (e.g. in order to log a communication's content).  Because the latter is more expensive, it is not often the default, but when it is required, CONNECT will never be substituted for it.
Is that a fair reformulation of your point?
[YN] Yes, this is true for firewalls and content filters. Since writing this, I got convinced that caching proxies might be willing to allow either CONNECT or GET at the client's discretion.

If so, I tend to agree, with two caveats:  because the whole system tends to be more heavyweight in support calls this configuration set is more rare than it should be; there are cases where the second configuration is the overall default (because it is simpler to configure and there is no capacity constraint for that particular system).
[YN} I'm pretty sure that explicitly configuring the proxy on all clients is the major cause of support calls. If (like today) it requires messing with the trust, that's a big additional cost to acting on a flow.

To return to Stephen's point, I don't see any harm in declaring CONNECT to be the default semantic, but I agree that there is a clear need to improve the other proxy semantics.  If an explicit proxy can only tell a client on a per destination basis that it doesn't support CONNECT, using it will mean a big performance penalty much of the time.
[YN] I think I agree, although I still don't know what "default" means in this context. The client can ask for either semantic, and the server can accept, deny, or deny while hinting that the other one would work. Either way, the client has to ask for a semantic explicitly. There's no default.  I can see something like this working, though. Of course you'll have to use authenticated TLS with the proxy for that.

CONNECT tools.ietf.org:443 HTTP/1.0

405 Method Not Allowed

GET https://tools.ietf.org/


200 OK

If that's the sense of "default", then I'm fine with it.

Yoav