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

[elijah]

On 08/28/2014 11:18 AM, Moxie Marlinspike wrote:

> a) Users are the only ones who know what their keys actually are, and
> whether they were supposed to change.
> 
> So we're in a situation where the best a "monitor" can do is provide the
> user with a view of their key state over time, which the user can verify
> with their own knowledge of what their key state should be.  Nobody can
> detect an attack but the user themselves, which they depend on a third
> party service in order to be able to do.  Everything is dependent on the
> user.

Indeed, as I tried to say earlier, for me the consequence of this is
that there must be heavy logic running on behalf of the user on some
device the user has chosen to trust[1]..

There are a lot of open questions in what this logic should be.

(1) precisely when is a new key accepted in place of a prior key? For
example, if I have a validated Bob's key via a manual verification, but
then a key directory publishes an entirely new key, which key takes
precedence?

(2) precisely when and how are users asked to manually intervene?
(keeping in mind that doing so is going to confuse the hell out of most
people).

If, as you say, key directories in practice will experience a lot of
suspicious flapping, this is a very important real-world constraint. I
have probably re-generated my TextSecure key four times. One approach is
to simple not make this kind of thing possible (would could lead to a
lot of people getting angry when they are shut out of their email).

> I'm really interested in hearing why partisans of the CT-style key
> directory think the overhead and other drawbacks are worth doing it over
> the simpler thing?

Although not an advocate of CT-style directory, I am an advocate for
infrastructure that includes key directories and key endorsers. The only
added benefit of infrastructure over in-band TOFU is the cold call: I
want to make the first contact slightly less dicey. Some might consider
this minor, but I think this scenario is more important in real-world
usage than we typically give it credit for. Also, it opens the
possibility of doing revocation and re-keying in the future, once
someone figures out an actually reasonable way to do that. Seems
reasonable, especially when users don't actually control their
identifiers (in this case, email address).

-elijah