On Thu, Aug 28, 2014 at 11:18 AM, Moxie Marlinspike <[email protected]> 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 [email protected] https://www.imperialviolet.org _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
