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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
