Posted by Virus Bulletin on Mar 12, 2015
Protocol has all the advantages of email, yet is orders of magnitude more secure.
In the current Internet era sometimes referred to as 'post-Snowden', it is often said that email is broken. After all, a lot of email is still flowing over the Internet unencrypted, and even if encryption is used for email delivery, that still leaves the mail servers as weak points that have access to unencrypted emails.
Using PGP to encrypt emails could solve some of these issues, but PGP leaks some important metadata. Moreover, more than 20 years after PGP was invented and more than 20 months after Snowden started leaking NSA slides, PGP's user base remains extremely small. Most crypto experts agree that it is time for the protocol to die and that they wished they could uninstall it.
Yet replacing email with something better is hard. First, the lack of encryption in email doesn't exactly affect most people's daily lives, and a lot of the concerns about mass surveillance are philosophical rather than inspired by a threat felt daily. Secondly, no matter how broken it is, email works. It takes two to message, and no matter how hard you want to use something else, if your contacts just use plain email, you are left with little option but to do the same.
Enter the 'Darknet Internet Mail Environment', or 'DIME' for short.
DIME is a protocol that is currently being developed to gradually replace email. Having finally taken the time to read through the specifications (pdf), I am very excited about what it could do.
The main clue is in the word 'gradually'. DIME doesn't throw away email; rather, it builds a new protocol next to it, allowing servers and mail clients to support both DIME and email at the same time. For many users, the gradual change they experience will be about as intrusive as Windows removing its 'Start' button. Perhaps even less so.
Those developing DIME show a clear understanding of how people use email today. Many users put a lot of (implicit) trust in their webmail provider, which has access to all their emails. Looking at it purely from a privacy point of view, this is horrible, but it's good to note that intelligence agencies aren't part of many people's threat models, no matter how hard you argue that they should be.
DIME gives users the option to trust their providers' servers, while also allowing for a 'paranoid' mode, where those servers see as little information as they would need to transport messages to their intended recipients.
Finally, to quote Ladar Levison, one of the people behind the protocol: DIME allows for someone to send 'an encrypted message without them having to get a Ph.D. in mathematics first' — which, given how little understanding most people have of cryptography, is an essential, yet often overlooked property of any encryption-based protocol that aims to achieve widespread adoption.
DIME is still very a much work in progress, and 'TBD's are scattered all over the specifications. Still, these specifications make it clear that DIME is based on two simple, yet essential ideas.
The first idea is a relatively small modification to the MIME standard for sending multipart email messages. Called D/MIME, DIME messages look very much like multipart emails, except that every part is encrypted and can only be unencrypted by the entity that needs to read it.
In normal email, if [email protected] sends a message to [email protected], Alice needs to tell hermail.com's mail server that she has an email for [email protected]. The email is then sent to hismail.com's mail server, which is told that there is a message from [email protected]. Even if Alice and Bob use PGP — which would make them part of an extremely small minority — this process leaks very important metadata. If Bob is known to have received information from a whistleblower, then a quick look at his mail server will point to Alice as a prime suspect.
In DIME, however, the only part of the message that hermail.com's mail server can read is the part that states that this is a message that is destined for someone with a hismail.com email address. Likewise, all that hismail.com's mail server can read is the part that states that this is a message that came from hermail.com, because that is the bit that is encrypted with its public key. It cannot read the email, and it cannot see which address sent the mail.
And that is because of the second idea: the Dark Mail Transfer Protocol, or DMTP.
DMTP is an extension of SMTP that is used to deliver DIME messages. Its delivery mechanism is very similar to that of SMTP, except that less data is visible. For instance, the arguments to the MAIL command only contain the sending domain, rather than the sender's full email address.
But apart from the delivery, DMTP is also used to retrieve the public keys used to verify the authenticity of a message or to encrypt parts of a message. Bob's mail client, for instance, connects to hermail.com's server to ask for Alice's public key, to verify that the message was really sent by her.
If your task is to protect whistleblowers or human rights activists living under oppressive regimes, you are not going to be particularly concerned with emails selling Viagra or phishing for your banking details. Nor should you. Yet spam is a serious problem for email today.
True, the problem is extremely well mitigated — which is why email continues to be used so widely today. But this mitigation may fail if email is changed in significant ways, which is exactly what DIME does.
Spam filters operate by reading the content and metadata of spam and (implicitly) checking this against a database of known spam. DIME does away with a lot of this metadata, while the encryption means that the only meaningful place to run a spam filter would be inside the mail client. Most of today's spam filtering takes place at mail servers.
The ability to provide feedback is used by many filters to improve their performance. Nothing would stop a DIME user from submitting a spam message they have received to their spam filter's servers, yet the risk of a user inadvertently sharing a confidential email this way might make spam filter developers more reluctant to implement such feedback mechanisms.
There is also nothing to stop a spammer from signing and encrypting their messages; the fact that DIME messages are always encrypted and signed won't, in itself, help against spam.
On the other hand, the fact that DIME messages are always signed makes it easy for spam filters to block malicious senders or domains. They don't even have to rely on users' feedback to do so: setting up a number of DIME spam traps might suffice.
Moreover, the mandatory encrypting and signing of messages means that sending spam doesn't scale as well as it does for email. In part, this is because both operations take significant resources. This isn't a significant problem for a mail client, or even for a corporate mail server; however, it is a problem for those trying to send as many emails as possible.
More importantly, DIME requires the availability of a server for verification of public keys. It is possible for spammers to set up such servers, but there is likely to be a huge bottleneck in their spam campaign. They will be subject both to takedown efforts and IP address blocking.
Hence I believe that, while DIME won't stop spam, it will considerably reduce its volume. Spammers will be forced to use smaller, more targeted campaigns, possibly using compromised accounts.
That won't automatically be a good thing: small campaigns are much harder to block (and even more so if they use compromised accounts). However, given how successful we have been in the fight against spam, I am sure we will be able to mitigate the possible future threat of DIME spam rather well.
Despite being very much a work in progress, the DIME specifications are sound and show a clear understanding of both cryptography and email — which shouldn't come as a surprise given the credentials of the people involved, including Ladar Levison (of Lavabit), Phil Zimmermann (who invented PGP) and email-veteran Dave Crocker.
Apart from allowing for mail servers to run in dual mode during the undoubtedly long transition period, DIME also doesn't change two important properties of email: the fact that it is asynchronous and that unsolicited messages can be sent. That will make the chance of adoption far more likely.
The specifications are worth a read, and also include a chapter on possible threats, as well as many details on how the protocol aims to prevent adversaries from supplying incorrect key data for their targets.
Now is also the time to provide feedback on the document and on making sure the encryption is done well: no matter how brilliant the philosophy behind DIME is, if the encryption is broken, then the protocol essentially becomes worthless.
Hopefully before too long, DIME will be ready for implementation. I hope it will receive the support of some large mailers, many of whom have explicitly expressed their concerns over the lack of encryption in email. But even if those mailers don't join straightaway, smaller organisations and individuals can start using it, hoping for others to follow suit.
Next week, I will be giving a presentation "The State of Email in 2015" at the TROOPERS15 conference in Heidelberg, Germany. In it, I will discuss the state of the fight against spam, and also spend some time discussing DIME.
