Re: Semantics of HTTPS


------ Original Message ------
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>Hiya,
>
>On 09/14/2012 12:46 AM, Adrien W. de Croy wrote:
>
>>
>>
>>------ Original Message ------
>>From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>>
>>>
>>>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.
>

ok, I view (mis)behaviour as a superset of misbehaviour.

I still think it's opinion.

As long as we view MITM as fundamentally evil, we will fight it instead 
of accepting it.

As long as we fight it, it will be done poorly.

Because whether or not the IETF likes it, customers want it, and 
vendors will supply it.

IMO we can do it better if we accept the legitimate need and design for 
it, rather than fighting it.

>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.
>
I agree it's controversial, and has difficulties.

But just because it may be difficult to cover all scenarios, doesn't 
mean we should not attempt to cover any.

>
>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.
>
no AV is perfect.

Customers like gateway malware scanning.


>>
>>I don't know that it gets anywhere trying to make everyones' decisions
>>for them.
>>
>
>
>Huh? Tone-down rhetoric time?
>

I was referring to your prior comment:

"Asking the user if they approve of a middlebox "seeing" their
traffic seems fairly broken to me really. Why would we expect
that'd make any sense to users?"

I took that as proposing there is no point asking people for a 
decision, and therefore we should make it for them.

>>
>>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."
>

it's possible that lack of a properly thought out way to allow 
legitimate scanning of HTTPS has resulted in a worse situation than if 
it had been designed for, since now we have a bunch of MITMs, and no 
clients moan, and no servers know that the client is intercepted.


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

Adrien


>
>
>S.
>
>
>>
>>
>>Adrien
>>
>>
>>>
>>>
>>>
>>>S
>>>
>>>
>>>
>>>
>

Received on Friday, 14 September 2012 01:15:56 UTC