Re: What will incentivize deployment of explicit proxies?

On 12/09/2013 11:59 PM, Mark Nottingham wrote:
> 
> On 9 Dec 2013, at 7:40 pm, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
> 
>> 
>> Messing with root stores sounds like a TLS MITM rather than
>> addressing proxies in HTTP since not all such stores are protocol
>> specific. That would be a significant issue.
> 
> People are already messing with root stores. 

Really? Using some IETF standard protocol? We actually have
one of those (RFC 5934) that afaik has had zero deployment
even though if I recall correctly, the folks behind that
did try to interest browser makers. I think they were told
that the browsers preferred to manage roots as part of their
s/w update. Has that changed?

> What I'm talking about
> below is placing constraints on how they can do that, and making the
> messing more visible to end users.

And you're going to do that analysis of how that'd impact
on all other consumers of TLS?

I'll also be interested in how end users will be protected
from root-insertion attacks from pretty much anywhere if
this becomes anywhere near common.

S.

> 
> Cheers,
> 
> 
>> 
>> S
>> 
>> Adrien de Croy <adrien@qbik.com> wrote:
>>> 
>>> and DLP (data leakage protection)
>>> 
>>> 
>>> ------ Original Message ------ From: "Roberto Peon"
>>> <grmocg@gmail.com> To: "Mark Nottingham" <mnot@mnot.net> Cc:
>>> "HTTP Working Group" <ietf-http-wg@w3.org> Sent: 9/12/2013
>>> 5:17:26 p.m. Subject: Re: What will incentivize deployment of
>>> explicit proxies?
>>>> 
>>>> 
>>>> 
>>>> On Sun, Dec 8, 2013 at 6:33 PM, Mark Nottingham <mnot@mnot.net>
>>>> wrote:
>>>>> This thread makes me wonder if, rather than focusing on
>>>>> introducing a
>>> 
>>>>> new kind of proxy to address the “enterprise/school/prison”
>>>>> (ESP) use
>>> 
>>>>> case, we* should instead focus on fixing how trust roots are
>>>>>  configured and managed in browsers / OSs.
>>>>> 
>>>>> I say that because the requirement is already being met in
>>>>> the
>>> market;
>>>>> ESPs are able to inspect and modify traffic as it goes by on
>>>>> the wire
>>> 
>>>>> by configuring a new trust root. It’s just that there are
>>>>> some nasty side effects brought about by that solution.
>>>>> 
>>>>> We may be able to mitigate the bad effects of the current
>>>>> solution — e.g., by allowing the user to understand when
>>>>> their browser is using
>>> a
>>>>> trust root that was added later (AIUI some versions of Chrome
>>>>> already
>>> 
>>>>> do this visually?), by giving the user more fine-grained
>>>>> control over
>>> 
>>>>> what new certificates can be used for (to address the BYOD
>>>>> user),
>>> etc.
>>>>> 
>>>>> If we can do that, we avoid the potential for new security
>>>>> choices in
>>> 
>>>>> front of non-enterprise end users, ones that Will is
>>>>> justifiably nervous about (since anything that would allow a
>>>>> MITM warning to be clicked through is a VERY attractive
>>>>> attack vector).
>>>>> 
>>>>> The one thing that wouldn’t be addressed by this approach is
>>>>> the potential for a “semi-trusted” proxy that can see inside
>>>>> encryption and yet promises e2e integrity. So, to me it seems
>>>>> like we should be focusing on the use cases that lead us
>>>>> there (rather than on that particular solution, yet).
>>>>> 
>>>>> The one that’s been clearly identified is shared caching; is
>>>>> there another?
>>>> 
>>>> malware/virus scanning
>>>> 
>>>> -=R
>>>> 
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> 
>>>>> * for some value of “we". Not every problem needs to be hit
>>>>> with an HTTP-shaped hammer.
>>>>> 
>>>>> 
>>>>> 
>>>>> On 7 Dec 2013, at 7:26 am, Werner Baumann 
>>>>> <werner.baumann@onlinehome.de> wrote:
>>>>> 
>>>>>> Am Tue, 3 Dec 2013 10:53:26 -0800 schrieb William Chan (陈智
>>>>>> 昌) <willchan@chromium.org>:
>>>>>> 
>>>>>>> 
>>>>>>> <pushback> I can probably expect to be tarred and
>>>>>>> feathered by my security
>>>>> team
>>>>>>> if I tell them we need to put up a UI asking the end user
>>>>>>> to make
>>> a
>>>>>>> decision about security :) </pushback>
>>>>>>> 
>>>>>> Yes, that's the problem with your security team. Talking
>>>>>> about
>>>>> security
>>>>>> for the end user, but the one party that has no saying is
>>>>>> the end
>>>>> user.
>>>>>> 
>>>>>> Talking as an end user: It is me, and only me, who decides
>>>>>> whom to trust in which respect and to what extend. It is
>>>>>> not your security
>>> 
>>>>> team.
>>>>>> 
>>>>>> Sure, there are users who don't care. And there are lot of
>>>>>> users
>>> who
>>>>>> can't make informed decisions, because all the necessary
>>> information
>>>>> is
>>>>>> hidden from them, many times by UI-experts who work based
>>>>>> on the
>>>>> dogma
>>>>>> that users are stupid.
>>>>>> 
>>>>>> Werner
>>>>>> 
>>>>> 
>>>>> -- Mark Nottingham   http://www.mnot.net/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
>> 
> 
> -- Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 
>

Received on Tuesday, 10 December 2013 00:26:52 UTC