Re: Semantics of HTTPS

On Thu, Sep 13, 2012 at 9:58 AM, Carl Wallace <carl@redhoundsoftware.com>wrote:

> From: Phillip Hallam-Baker <hallam@gmail.com>
> Date: Thursday, September 13, 2012 9:47 AM
> To: Carl Wallace <carl@redhoundsoftware.com>
> Cc: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, Stephen
> Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>,
> "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <
> ietf-http-wg@w3.org>
>
> Subject: Re: Semantics of HTTPS
>
>
> I see the following approaches as possible:
>
> 1) Do nothing
>
> Ignore the issue completely, let parties work around the infrastructure as
> deployed without making allowance for the requirement.
>
> 2) Attempt to disrupt
>
> Attempt to design the protocol so that the intercept requirement cannot be
> met in any circumstance. This is actually the traditional IETF approach.
> The risk here is that people create their own work arounds and loopholes
> and then demand that infrastructure supports it and the systems that result
> do not provide for informed consent.
>
> 3) Provide a comprehensive mechanism that is conditioned on informed
> consent.
>
> If we decide that preventing intercept is possible the next best outcome
> is to enable intercept but only with informed consent.
>
>
>
> If we want to support that particular use case we have to have the client
> delegate its whole process of trust evaluation to the accepted interceptor
> and at minimum constantly inform the user that this has occurred. We may
> also decide that we want to inform the service that the user is connecting
> to that an intercept has occurred.
>
>
> So you'd sacrifice e2e authentication.  That's one way.
>

I did not state which of those choices I would take, I merely stated that
those are your choices. The choice that people seem to be 'choosing' here,
e2e security with MITM client-side proxies doth not exist. It is a
contradiction in terms.


It is possible to have e2e authentication without e2e confidentiality. But
TLS is really not designed to address that use case as they began with
confidentiality and added in integrity as an afterthought after Alan
Schiffman and I broke SSL 1.0. Mutual authentication was an afterthought on
an afterthought.

What I am trying to push people towards here is to face the decision they
are making. If you want to put a proxy in the middle of the communication
and look at the packets then it isn't going to give e2e confidentiality, if
you want to allow the proxy to modify the packets then you haven't got e2e
integrity or authentication.

Those criteria are by definition.


If people want to argue that those cases should be supported and can
explain how notice, knowledge and informed consent can be achieved then we
can start a discussion about how to achieve them.

-- 
Website: http://hallambaker.com/