Re: Draft finding - "Transitioning the Web to HTTPS"

I have actually been consulting with a friend who is the chief security
expert at a famous public company (cloud infrastructure) and he thinks
people on this list are narrow minded as there are plenty of opportunities
to design a decentralized security model, not one that would necessarily
replace https but could use it to download the script securely (as a
browser extension) and then use it to implement a secure decentralized
security model that would work over http.

Neither of you have responded to the question of why browser extensions
downloaded securely and relying on web crypto or native apps couldn't
implement a decentralized security model. You say convergence.io suffers
from lack of performance and you throw arbitrary statements like "giggle
test" at a very similar idea.

That friend, who had written books on the subject of network security and
like I said is in higher regard in this field than most if not all "wanna
be security experts" on this list, is willing to take to the blogosphere to
write about this and to use this thread as a reference. I might take him up
on his offer now that I see the resistance is not logical but ideological.
I had more hopes in the "TAG" I honestly did, until the "giggle test" was
thrown out there. How ridiculous and juvenile of you to demean rather than
argue against each given point. I do admit that my argument was lacking but
I kept refining it based on your input until it got to the point of "hey if
convergence.io can do it with a plugin downloaded via https and used over
http" then why couldn't everyone else do the same and experiment with the
innovative and exciting models timbl mentioned? Why not? What is your
security expert alter ego telling about it's a bad idea?

Thank you.

Marc

On Sat, Dec 20, 2014 at 1:50 PM, Mark Nottingham <mnot@mnot.net> wrote:

> +1 here. This sort of approach isn’t likely to pass the giggle test in any
> security community, not only because of bootstrapping, but also because of
> the homemade crypto problem.
>
> WRT “blanket the whole web” — I want to emphasise that the goal here is
> not to make everyone deploy TLS against their will; it’s to a) make sure
> that TLS is used for features that expose powerful features, and b) reduce
> the barrier to entry to using TLS. This gets us to a place where *more* of
> the Web uses TLS, which means that more private data, behaviour, etc. is
> protected — and it also means that there’s a stronger ecosystem of
> crypto-using sites, making things like pervasive monitoring more difficult
> as well. If a site really wants to use unprotected HTTP and don’t need to
> use any new powerful features, they’ll still be able to.
>
> Cheers,
>
>
> >
> > Why are you so intent on reinventing secure transport with WebCrypto? Is
> this some sort of everything-must-be-JavaScript thing?
> >
> > We have a system that works. Use it. Don't reinvent a new one, spend ten
> years discovering the myriad of flaws, and then another twenty trying to
> get wide adoption.
> >
> > I really see no reason to "help out" with this quixotic campaign.
> >
> > -----Original Message-----
> > From: Marc Fawzi [mailto:marc.fawzi@gmail.com]
> > Sent: Saturday, December 20, 2014 08:27
> > To: Domenic Denicola
> > Cc: Tim Berners-Lee; Eric J. Bowman; Chris Palmer; Melvin Carvalho; Mark
> Nottingham; Public TAG List
> > Subject: Re: Draft finding - "Transitioning the Web to HTTPS"
> >
> > Domenic
> >
> > What Tim laid out is exactly why I'm excited about web Crypto, but you
> have a point about the initial download of whatever system implemented on
> top of it.
> >
> > What if the system was built into a Chrome extension and downloaded via
> https from the Chrome Web Store? I had a chat with the developer behind
> AdBlock and he actually wrote a script to check periodically to make sure
> his extension on the Chrome store hasn't been replaced with a non-official
> version. He said its for potentially rogue employees. He had hired some
> developer(s) to take over the development of the plugin. In the same way,
> plugin developers can release sensitive plugins on the chrome web store and
> users can be sure that they're downloading the valid version (via https)
> After that, everything Tim said (which is inspiring btw) should be
> implementable and can work over http.
> >
> > So can we just not go knee-jerk and blanket the web with https when it
> may only be needed in a few places (assuming web crypto based systems will
> be developed as built in browser functionality or as plugins downloaded
> from browser vendor's store?)
> >
> > Help us out here!
> >
> > Sent from my iPhone
> >
> >> On Dec 19, 2014, at 7:51 PM, Domenic Denicola <d@domenic.me> wrote:
> >>
> >> From: Tim Berners-Lee [mailto:timbl@w3.org]
> >>
> >>> Yes, but once the webcrypto code is unpolyfilled into the browser that
> attack will go away, and you will be able to use it to build new trust
> systems, right?
> >>
> >> No, sad to say. Since the network attacker could modify whatever
> JavaScript code you are using to implement those trust systems, or could
> even simply insert something like
> >>
> >> Object.defineProperty(window.crypto, "subtle", {
> >> get() {
> >>   return new CompletelyFakeWebCryptoImplementation();
> >> }
> >> });
> >>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>