W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Semantics of HTTPS

From: Carl Wallace <carl@redhoundsoftware.com>
Date: Thu, 13 Sep 2012 09:58:24 -0400
To: Phillip Hallam-Baker <hallam@gmail.com>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <CC775CE1.26FBC%carl@redhoundsoftware.com>
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"
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.
Received on Thursday, 13 September 2012 13:59:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC