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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
