It is not so easy to find ones way in the post-Snowden times. A myriad of thoughts, some well thought through, some less are surfacing giving the user mostly security theater (© Bruce Schneier, I would say) and some half cooked good ideas. Now here is something, that is still in-between, but could develop into something useful, if done right.

If a service provider is lavabitten to hand over their data, it is very hard to say “nay”!  Therefore, all the approaches that leave mail bits and pieces freely accessible on a server (“somebody else’s hard drive”) in the cloud, even if encrypted using SSL between the endoint and the server and between the mail server of the service providers and other service providers, e.g. those of the recipients, are not really valuable.

Now, there are a myriad of legitimate wishes to keep prying out of communication, for example lawyers, tax-adviosors, the medical profession etc. The typical malevolent person would, if they are up-to-date, not send any incriminating material over the net anyways. Journalists and members of any administrative entity are to be added to the list of persons that would definitely benefit from the privacy in email.

Sending encrypted email still leaves metadata available, and as everybody could have learned from the Snowden docs, this is sometimes telling more than actually reading the mail content.

One of the fundamental problems with email is that the meta-data routing information is exposed as cleartext. Encrypting a message with OpenPGP or S/MIME does nothing to help with this.

The email protocol does support an optional method of securely relaying messages using TLS to encrypt the connection. This method, called StartTLS, is easily undermined by attackers and there is no good way for email providers to validate the authenticity of other servers (without relying on the problematic CA certificate authority system).

For now, LEAP addresses these problems with two enhancements when two compatible providers are talking to one another:

• When relaying email, server keys are discovered and validated using DNSSEC/DANE.
• For these providers, TLS with validated keys becomes required for all communication.

say the inventors of leap.se ( Email and its discontents – leap.se).

The work these folks are doing, has the typical user in mind, that would wish to continue using their email client (say, Thunderbird or Apple mail), but not compromise on the content. Columbia Journalism review has an interesting article on the topic, as they represent the writing profession here: “easy email encryption”.

The LEAP guys are planning to have client-side encryption and offer a user-facing part and also (a vital part) a service provider element. The reason for this is to enable non-leaking end to end, metadata-considering email services, while of course keeping some compatibility to legacy services. But having LEAP compatible service providers talking to each other carries a lot of benefits, see quote above.

More services, based on the same framework are planned (e.g. messaging etc.). But the major problem in today’s environment of unstoppable data-hunger in everyone, continues to be the email stream of meaningful content.

There are, of course limitations. It has been beyond me why anyone would wish to use a browser to access their email, but, alas there are some that do. This, of course will not work with LEAP. To me, this does not seem to be a limitation, but some may feel like it is. Then, there is the current need for a provider that actually supports the server-side part, which will, with some likelihood be changed later.

All in all, the ideas seem to be pretty well thought through on first glance. Putting more brains to work on auditing and checking, of course, will show whether the approach is, in fact, the new panacea.