Last May, I was in Hong Kong for OpenITP’s Circumvention Tech Summit – and I ended up taking an afternoon walk with none other than Daniel Kahn Gillmor. Over a 7 hour and I-have-no-idea-how-many-kilometer walk, we talked about a ton of things, until I eventually asked him “Why don’t you think we have email encryption?”
We talked about a lot of the hard problems of email encryption – problems that are difficult to solve while still being intutive and easy for non-technical users, and not disrupting their preferred workflow. Things like Key Discovery and Key Auththenticity, webmail, and moving keys between devices.
We were kind of beating around the bush, and finally I just said what we were both thinking: “Maybe providers should manage keys for most people.” He agreed that this seemed like the best way to get wide adoption. (Remember, this was all pre-Snowden.)
We chatted some more, about key discovery in DNS (which would later be amended to HTTP), about encouraging email providers to do encryption on behalf of users, and more importantly (to us, as well as you I’m sure) – allowing users to manage their own keys and upload the public component.
What we saw was ubiquitous email encryption, where every email sent between major participating providers is encrypted. And in a large percentage of cases, it’s encrypted provider-to-provider. But in a small percentage of cases – it’s encrypted provider-to-end or end-to-end. We feel that if email encryption really was ubiquitous, the clients we have now (Enigmail, S/MIME in Outlook and so on) would be developed and promoted to first class citizens, and things like browser extension-based email encryption would be fleshed out considerably. So while the early adopters (the people who use email encryption today) would use the painful tools we have now – there’d be a huge investment in tool development, and .01% of users would grow to .1%, and then 1%, and maybe to 10%.
We laid out as many pieces as we could, specifying a key discovery mechanism that doesn’t leak metadata, signaling information to learn if a provider (and user) has opted in to email encryption while blocking downgrade attacks, a report-only mode to prevent a flag day, a minimal level of key authenticity that can optionally be increased on a provider basis, failure reporting, enrollment steps for the many different ways email accounts are created on the web, and some suggestions for encrypted message format.
And then a few months later, a man named Edward Snowden came into our lives.
The PRISM revelations reveal widespread complicity on behalf of centralized email providers, but more importantly they reveal a broad overreach of the government, and the disturbing trend towards rule by secret law.
We still like this protocol, even post-Snowden. An encrypted email solution that requires end-to-end encryption, with no provision for an email provider to read the mail, is unlikely to be deployed by large corporations that have regulatory monitoring and reporting requirements – industries like large Law Firms, Financials, and Healthcare – plus all business that have to support E-Discovery andData Loss Prevention. You may not like those things (and you may be morally opposed to them), but they are what companies require or have to live with. Those organizations could try to meet some of these requirements under an end-to-end encrypted e-mail scheme (for example, by operating key escrow services), but having direct cleartext access to their users’ mail is technically much simpler. By making these use cases a standard, and making the feature as visible to mail users as https is to people who browse the web, we hoped to get large companies on board and have them share the initial development and deployment cost. We aimed for ubiquitous email encryption – business-to-business, between work email accounts and personal accounts. Yet another fragmented internet, where only a few of our contacts supported encryption, was no more interesting than the status quo.
But although we like it, the current situation in the US and the requirements placed upon (and cooperation of) large companies like Google and Verizon means that granting the provider a centralized place of trust in email encryption is a non-starter. And as a complicating factor, the thing the government has been most interested in has been metadata – the very thing that is afforded the least protection under the law and simultaneously the most difficult to protect in a point-to-point protocol. There are efforts to fight this technically (like Tor), but we feel the legal atmosphere must change as well as the technical infrastructure.
We’re posting our specification and supporting documents online for people to refer to, in the public domain. It’s over on github.. Email encryption is hard, and when you start thinking about all the corner cases (like automatically putting mailing list footers into a signed message) – it gets harder. We’re hedging our bets. We hope that the legal atmosphere changes. Barring that, we hope this document and its appendixes help other people look at the problem and make progress where we got stalled.
Oh yea – what’s it called? Well, when we walked around in Hong Kong, we were calling it “STEED-Like”, after Werner Koch’s STEED Proposal, which we drew inspiration from. When we realized how much we deviated from it, we dubbed it UEE for Universal Email Encryption – with the intention of finding a better name when we released it. But that day never came. So until we have a legal environment where this might make sense… pronounce is like wheeeeeeeee, but with a you in the front. YOU-EEEEEEEEEEEEEEEEEEEEEEEE!
The biggest argument we’ve seen against this proposal is that StartTLS (TLS-encrypted SMTP links between providers) gets you almost the same thing, for most users, with way less work. We love StartTLS and want to see it working way better than it does now. But we think that just getting to widespread email encryption (even if some or even most keys are provider-managed) would spur the development and smoothing out of client-based encryption, which would in turn let more people opt in to managing their own keys, getting true end-to-end security not possible with StartTLS.
via ritter.vg
