[messaging] Google End-to-End plans on using key directories with a CT-like verification protocol

[Joseph Bonneau]

On Thu, Aug 28, 2014 at 3:11 PM, Moxie Marlinspike <moxie at thoughtcrime.org>
wrote:
>
>  > Specifically, Google and Yahoo are large commercial entities that want
> > to operate an encrypted communication network without key escrow in a
> > way acceptable to their lawyers. The current operators of large e2e
> > networks(iMessage, BBM) use key escrow as part of their compliance
> > regime with lawful interception orders.
>
> Even in that context, I'd love to hear why you think "the simple thing"
> doesn't accomplish the same goals.


So with "the simple thing" proposed by Moxie (as I understand it), consider
that one party will probably be both the Key Directory and Message Transfer
Agent. So they can tell Bob that Alice's key is Y when it's really X, and
when when Bob messages Alice they intercept and re-encrypt. If the KD has
to sign all of its assertions, then Alice and Bob need to gossip out of
band to realize the KD is equivocating. To prevent this you want Bob to
sign what he thinks Alice's key is so even if Alice's KD changes the
encryption, they can't forge Bob's signature assuming Bob's KD/MTA is
honest.

If this were implemented and you could detect an equivocating server
assuming at some point one of its users talks to another user who has an
honest server. Two equivocating servers in cahoots could probably both
equivocate if a pair of their users was talking. The log/monitor setup
might be more resistant to this case, though you could similarly build
out-of-band gossip onto the "simple thing" case and get part of the way
there.

I think you can summarize all of the append-only log and monitor
infrastructure as apparatus to ensure that equivocation will be detected.
So perhaps either approach works at preventing equivocation and the "simple
thing" might be appropriately named. Unless we're missing something?

Either way, I agree that on the hard questions of determining ground truth
and not showing tons of spurious warnings we're exactly where we were when
the last thread on messaging transparency[1] died in March. There are still
painful edge cases like if Alice's client doesn't know that Alice enrolled
a new device with a new key yet and warns that a spurious key has been
added, which is I discussed over on Google's wiki for this project and
haven't heard a compelling answer for.

On the issue of legal cover to avoid serving national security letters,
hopefully Google's lawyers have thought this through and determined there's
some real value. We're not any further on this mailing list towards
answering that question either (which also came up before[1]).

[1] https://moderncrypto.org/mail-archive/messaging/2014/thread.html#226
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140828/9a3acd0a/attachment.html>