W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: What will incentivize deployment of explicit proxies?

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 09 Dec 2013 04:26:32 +0000
To: "Roberto Peon" <grmocg@gmail.com>, "Mark Nottingham" <mnot@mnot.net>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em6d0616cc-c14b-4624-90d6-c8eeed4a7a20@bodybag>

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 04:26:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC