- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 10 Dec 2013 11:44:21 +1100
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: Adrien de Croy <adrien@qbik.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 10 Dec 2013, at 11:26 am, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > > 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? In the sense that when you start a new job, you're told to go to a certain URL (RFC3986) and download (RFC2616) a new CA cert and install it into your root store, yes... Of course, other folks are using proprietary protocols to automate that, but I'm not talking about standardising that. I'm talking about what the browsers do with certs once they're in the store. > 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? Dunno. Browser guys? > >> 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? Sure. I'm thinking in terms of changes in browser behaviour (along the lines that some have already explored), not changing TLS, or even certs, necessarily. > 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. Well, at the least, they'd be as protected as they are now... > > 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/ >> >> >> >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 10 December 2013 00:44:52 UTC