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

Re: Semantics of HTTPS

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 13 Sep 2012 19:08:08 -0700
Message-ID: <CAP+FsNfRx7hAJgvemB2qQ8jq3Us8-1arSE3JS7AUOb0WC6+R1g@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Carl Wallace <carl@redhoundsoftware.com>, 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>
On Thu, Sep 13, 2012 at 6:47 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> <snip>
> 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.
>
>
100% agreement that we must pick one of these.

-=R
Received on Friday, 14 September 2012 02:08:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 September 2012 02:08:42 GMT