Re: What will incentivize deployment of explicit proxies?

+1.

Also, as I mentioned in another thread, cert pinning and DANE promise ways
to defeat MITMs in the future. Our protocol should provide support for
legitimate proxies even assuming MITM no longer works.

Peter


On Mon, Dec 9, 2013 at 3:40 AM, 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.
>
> 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/
> >>>
> >>>
> >>>
> >>>
> >>
>
>
>
>