Subject: [perpass] Great Critique of Lavabit - Client-encryption in the Web?

From: Harry Halpin <[email-masked]>
Date: Wed, 06 Nov 2013 12:48:33 +0100

I'm not sure what the plan is with the much hyped "Darkmail Initiative 
to replace email", but here's a great essay on how absurd Lavabit's 
security measures were as regards securing email:

http://www.thoughtcrime.org/blog/lavabit-critique/

In essence, sending everything around in plaintext and then encrypting 
on the server obviously doesn't count as secure email. I'd be interested 
in what people think are the best methods for doing client-side 
encrypted email.

In particular, Moxie notes that encrypted email is impossible to do due 
to lack of a usable non-Web mail client (I used to use Mutt, then moved 
to Thunderbird+Enigmail, but with every passing day Thunderbird gets 
worse and worse - perhaps due to Mozilla abandoning it.) since "Despite 
what anyone tells you, end to end encrypted email is not possible in a 
webmail world."

My question is: What could the W3C due to encourage client-side 
encryption? In particular, could we one day have encrypted 
communications in the webworld?  Right now the Web Security Model 
essentially states that the host is trusted 100%, but after the NSA 
revelations, for some use-cases this is obviously no longer enough, and 
it would be better to store data on the server client-encrypted. The W3C 
WebCrypto Working Group [1]'s API should enable client-side use of 
trusted crypto primitivies, but that's only one piece of the puzzle. 
What other parts are needed?

For example, currently the Web Crypto API allow JS to set the private 
key, then some simple JS tricks can be used to achieve everything that a 
developer might want:  effective key extraction, effective supercookie, 
etc. due to the fact that currently the API does not guarantee on 
providing secure key storage with the user agent and there is no user 
dialogue required to set a private key to extractable.

Another example would be that updates on the Web require trusting the 
website to always update the Javascript code correctly. However, one is 
often not sure how much Javascript is being imported from foreign 
sources, or even if the server is attempting to maliciously rewrite the 
Javascript Code. While work such as Thandy/TUF allows this problem to be 
solved for normal software updates [2], there is no secure updating 
mechanism for Javascript. One option would be for code to have integrity 
checks and be signed, and allow a diverse set of Javascript repositories 
then check the integrity check and signature via network perspectives 
across multiple repositories before executing the code.

There's obviously a lot of work to do. While the W3C has been fairly 
silent so far on this list, as a personal position I am completely 
against mass surveillance as I believe it's against the principles of a 
free society.  We need to improve our standards to make mass 
surveillance much, much more difficult. Good luck today everyone at IETF 
- wish I was there!

    yours,
      harry

[1] http://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
[2] 
http://google-opensource.blogspot.fr/2009/03/thandy-secure-update-for-tor.html