Ladar Levison is probably most well-known to Ars readers as the founder of the secure e-mail service Lavabit, which he shut down in mid-2013 in an effort to avoid being forced to comply with a US government demand to turn over users e-mails. But his latest project is a lot grander in scope than a single hosted e-mail service: Levison is attempting, with the aid of some fellow crypto-minded developers, to change e-mail at large and build encryption into its fundamental nature. <\/p>\n
As one of the members of the Darkmail Technical Alliance, Levisonalong with Jon Callas, Mike Janke, and PGP designer Phil Zimmermannis working on a project collectively referred to as DIME, the Dark Internet Mail Environment. DIME will eventually take the form of a drop-in replacement for existing e-mail servers that will be able to use DMTP (the Dark Mail Transfer Protocol) and DMAP (Dark Mail Access Protocol) to encrypt e-mails by default. <\/p>\n
Conceptually, DIME applies multiple layers of encryption to an e-mail to make sure that the actors at each stage of the e-mails journey from sender to receiver can only see the information about the e-mail that they need to see. The e-mails author and recipient both know who sent the message and where it was bound, but the authors e-mail server doesntit can only decrypt the part of the message containing the recipients e-mail server. The recipient e-mail server knows the destination server and the recipient, but it doesnt know the sender. So if you arrange the four steps in a line from left to rightauthor, origin server, destination server, and recipienteach step in the line is only aware of the identity of the entity directly to its left or right. <\/p>\n
Making this work means relying on a federated key management system to handle the layers of encryption, since every entity in the DIME chain has to have its own public and private keypair to encrypt and decrypt the portions of the e-mail that it needs to be able to encrypt or decrypt. Levison envisions this working in somewhat the same manner as DNS, with each organization that uses DIME being the authoritative source for encryption keys for its servers and e-mail addresses. Levison has settled on DNSSEC as being the preferred method for holding a domains e-mail trust anchor, but DNSSECs poor adoption means the protocol will also allow the use of a root Certificate Authority-signed TLS certificate to validate keys. <\/p>\n
Levison is doing the initial implementation of DIME using a fork of Lavabits Magma e-mail server, but the plan is to eventually have support for DIME in Postfix and other common Mail Transfer Agents. In e-mail terms, the DIME Magma-based server functions sort of like Exchange, combining the roles of Mail Transfer Agent and Mail Delivery Agent into a monolithic server. If a users e-mail client (the MUA, or Mail User Agent) doesnt support DIME, the spec allows the DIME server to transparently generate keys for the user and encrypt the users messages on their behalf. <\/p>\n
\"You update your MTA, you deploy this record into the DNS system, and at the very least all your users get end-to-end encryption where the endpoint is the server, Levison explained during a phone interview with Ars. And presumably more and more over time, more of them upgrade their desktop software and you push that encryption down to the desktop.\" <\/p>\n
This optional mode wherein the e-mail servers transparently do the clients encryption for them, is called trustful mode and can either be a bridge for users to until they have a client program that fully supports DIME, or a way for large organizations with legal discovery or regulatory requirements to use DIME but still have access to their users e-mails as needed. It also provides a way for e-mail hosting companies to potentially deploy DIME for hosted accounts without having to worry about what mail clients their customers are using. <\/p>\n
From an encryption perspective, DIME will allow some flexibility, while at the same time attempting to ensure some minimal level of security as part of the spec. The DIME toolset will mandate a base set of ciphers, and administrators setting up DIME can specify additional ciphers to use on top of that. According to Levison, DIME will use for ciphers a mandated baseline that I knew was secure, but make it easy to extend upon that.\" This will be done by encrypting the message components with whatever alternative encryption method the administrator prefers, and then wrapping each component in the mandatory encryption scheme on top of that. <\/p>\n
Adoption of DIME by the IETF as a formal set of RFCs would go a long way toward the likelihood of DIME support appearing in other more common existing MTAs like Postfix, rather than requiring administrators to set up Magma in order to take advantage of DIME. To that end, Levison intends to begin circulating the projects specifications document among members of the IETF at the groups meeting this March as a preliminary step toward transforming DIME into a ratified set of standards. <\/p>\n
For now, outside of the custom (and preproduction) fork of the Magma server used by Levison, DIME isnt yet fully available or implementable. There is a GitHub repository containing what Levison describes as pre-alpha libraries for DIME, and the team has assembled a 109-page specifications document, but the technology isnt yet in a state where it can be independently deployed and audited. <\/p>\n
<\/p>\n