Re: Explicit proxy options and defaults

"The explicit proxy should be just one of the players who
can say no in this game."

+1


On Sun, Dec 8, 2013 at 3:39 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie>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.
>
> (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.
> >>
> >>
> >
> >
>
>