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

Re: Semantics of HTTPS

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 14 Sep 2012 01:44:13 +0100
Message-ID: <50527DDD.4070402@cs.tcd.ie>
To: "Adrien W. de Croy" <adrien@qbik.com>
CC: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

Hiya,

On 09/14/2012 12:46 AM, Adrien W. de Croy wrote:
> 
> ------ Original Message ------
> From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
> To: "Phillip Hallam-Baker" <hallam@gmail.com>
> Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> Sent: 14/09/2012 2:56:21 a.m.
> Subject: Re: Semantics of HTTPS
>> On 09/13/2012 02:47 PM, Phillip Hallam-Baker wrote:
>>
>>>
>>> 3) Provide a comprehensive mechanism that is conditioned on informed
>>> consent.
>>>
>>
>>
>> I'm not at all sure that this option is even feasible for https.
>>
>> There is a 4th option: leave the e2e semantics as-is and write an
>> RFC called "HTTPS MITM considered harmful" that explains the
>> issues and trade-offs and says why we don't want to standardise
>> that (mis)behaviour.
>>
> 
> "misbehaviour" in this context is a subjective opinion.

(mis)behaviour != misbehaviour. The parentheses were meant
to signal that we appear to have a somewhat rough consensus
about that. But I reckon we do have rough consensus to not
standardise a TLS MITM, and I suspect that is likely also true
for an HTTPS MITM. The process of developing and last-calling
a BCP with such a title is in any case the IETF way to figure
that out.

> I think that pretty much amounts to sticking our heads in the sand.
> 
> If it's considered so harmful, why is pretty much every proxy vendor
> implementing it.

One might also ask if any banks whatsoever are asking for proxies
to do this. Are any? If not, or if almost all are not asking for
this, then I think we ought all recognise that attempting such a
so-called "trusted proxy" thing is controversial.

And then there's the issue that I at least have not seen any
proposed solution that doesn't have more downsides than
upsides. Feel free to show me yours in the form of an I-D.

> And is it more or less harmful than the harm caused by viruses, or
> browser hijacking sites which use HTTPS, for which we'd otherwise have
> no defence.

Are you saying that all desktop AV offerings are "no defence"? Seems
like an odd proposition.

> I don't know that it gets anywhere trying to make everyones' decisions
> for them.  

Huh? Tone-down rhetoric time?

> We argue why would anyone want to have their https traffic
> inspected, and assume that noone in their right mind would ever want
> that for any reason, even if the alternative was no access at all.  I
> propose you wouldn't actually have to look very far to find people who
> would trust their company enough to proceed to facebook or google search
> trusting that it was being scanned for malware.
> 
> You can't avoid a requirement to trust something.  Trying to avoid it,
> or pretending the requirement isn't there is IMO what causes security
> and trust problems in the first place.

Hmm. I  doubt that the lack of a MITM is significant *cause*
for "security and trust problems."

Overblown arguments on either side here IMO weaken the
overblown arguer's position.

S.

> 
> Adrien
> 
>>
>>
>> S
>>
>>
>>
> 
> 
> 
Received on Friday, 14 September 2012 00:44:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 September 2012 00:44:43 GMT