Re: What will incentivize deployment of explicit proxies?

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.

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/
>>>
>>>
>>>
>>>
>>

Received on Monday, 9 December 2013 08:40:44 UTC