Re: Semantics of HTTPS

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.