- From: Yoav Nir <synp71@live.com>
- Date: Mon, 9 Dec 2013 00:19:17 +0200
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <BLU0-SMTP203F52C82AD062A7BD48821B1D00@phx.gbl>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Sunday, 8 December 2013 22:19:38 UTC