[messaging] Transparency for E2E encrypted messaging at a centralized service

[Joseph Bonneau]

Here's an idea that arose between Daniel Kahn Gillmor and I (mistakes all
my own). Imagine you're a centralized web service and you want to offer E2E
encrypted messaging between your users. Hardening Twitter direct messages
could be a target, but potentially others.

The goals and requirements are limiting here and this is not going to be a
perfect system:
*most users can't install software and the browser is all they have (or
maybe an app in the best case)
*users aren't going to compare fingerprints. The user experience has to be
push-button
*the centralized service is a middleperson for all comms, no P2P or
out-of-band
*users must be able to use multiple devices seamlessly and not lose access
even if they lose all key material

So here's a proposal:
*Users can generate a private-key in their browser or app on demand
*Centralized service, after normal authentication (password, ideally
2-factor) issues certificates for these keys in browser using a private
service-specific CA
*Users can download certs from the central service for their contacts and
use these for encrypted messaging.
*The service runs a Certificate Transparency-style log for every
certificate it issues and a similar transparency log for revocation
(Revocation Transparency or Mark Ryan's Enhanced Certificate Transparency).
Users query these structures to get proof that the certs they are using are
genuine and not revoked.
*Outside auditors scan the log for correctness and provide a web interface
to check which certs were issued for your username and when.

This system could be built with very few changes to the user experience and
adds some security properties, namely E2E encryption and some visibility if
bogus credentials are ever issued due to a subpoena or compromise.

The main challenges are:
*Synching keys between devices. One option is password-protected private
keys you download from the service and decrypt in-browser. This has some
security downsides and is a pain. Another option is a device pairing
protocol similar to Firefox Synch, but this is also difficult. Finally, you
can just have multiple keys/certs per device, but this requires broadcast
encrypting messages. I'm not sure what's best here.
*Serving modified Javascript can violate security, and this might be the
attack that government subpoenas would demand. Though this would be
theoretically detectable, and might be legally riskier to demand.
*Messages to users who've never generated a key. Does the service
pre-emptively generate one on their behalf and hand it off to them? Or are
they unreachable until they opt-in to the new system?
*The number of users may be much larger than the number of web domains (100
M or more), with frequent updates, so running a transparency log is a huge
task, potentially much bigger than CT.
*Privacy. Is it okay to have a public structure with usernames, showing
every time they've asked for a new key?
*The usual issues with how many users will ever check the log, and if it
will be audited, as well as the desire for an outside party to run a log in
case the central service's log screws up due to a bug.

There's also a big legal question around if a NSL could force a service to
issue a certificate for intercepting messages which would leave public
evidence.

Again, the goal here isn't perfection. We'd like much stronger approaches
for users who can run their own software and not depend on a central
service. But we'd also like to have a one-click solution that could provide
some not-trivial-to-bypass encryption for traffic currently passing through
Twitter/Facebook/Gmail and the like.

Cheers,

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140325/4734f1b8/attachment.html>