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

[Adam Langley]

On Thu, Aug 28, 2014 at 11:18 AM, Moxie Marlinspike
<moxie at thoughtcrime.org> 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.

Yes, that's the basis of CT.

Fundamentally, *only* the user can say which keys are really theirs.
With my Google hat on, I've both contacted large sites in a hurry,
with a questionable certificate in hand, to ask "really? Is this you?"
and have received such inquiries myself too from puzzled outsiders.

CT was designed for the web PKI where keys change much less frequently
and knowing the set of keys purporting to be for your site is very
valuable. Sure, most sites would never care, but CT gives those that
do the ability to check. And, given the centralisation of the web, as
a percentage of all connections it can be quite a large number.

In the event of a problem we have to revoke, which is hindered by the
fact that the standard revocation mechanisms are all broken, but
browsers have shown several times that we can effect a cert revocation
when needed via CRLSets/CTLs/binary pushes. Also, if a CA issues a
certificate we expect them to be able to say who authorised it etc and
we can check email logs and the like. It's easier to point blame in
that case.


For email encryption there are major differences:

It's not reasonable for browsers to do TOFU because what's a user to
do? At least in the email case there might be a reasonable out-of-band
mechanism for someone to remember "oh, did you change phones?" the
next time they see a friend. I'm not sure whether key-change prompts
are reasonable in the email case, but they are certainly *more*
reasonable than on the web.

What's the revocation story in the email case? In the web case, the
admins of the large sites that generally get targeted have pretty good
contacts with each other so we can sort that out. If an email user
claims not to know a key I'm not clear what e2e proposes to do about
it. They have a paragraph that sounds like the Revocation Transparency
paper but that was based on CAs doing the revocation. I'm not sure
what the proposed authentication is if a user claims never to have had
a key.

> 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?

I guess you can call me a CT partisan but to answer your question,
I've not spoken with the e2e folks about it and I don't think that CT
is clearly better than your "simpler" design is this context, at least
not yet.


Cheers

AGL

-- 
Adam Langley agl at imperialviolet.org https://www.imperialviolet.org