Two weeks ago, many of the people on this list had the opportunity to meet in person and discuss further this question of key validation.
During that conversation, Moxie elaborated what he means by "the simple thing", as in "why not just do the simple thing for key validation?" For me, the most important distinction that Moxie made between the simple thing and the complex thing is this: Bob has a public key and Alice wants to know if this key is the right one. * The simple thing: Alice is responsible for key validation. * The complex thing: Bob is responsible for key validation. All the schemes that have been proposed, such as nyms, DIME, PPE, nicknym, logs, blockchains, etc, are predicated on the idea that Bob ultimately is the one who knows what his key is and the onus should be placed on Bob for ensuring that the key other people see (either in a log or via key directories or dns or whatever) is the right key. If I recall correctly, Moxie's counter argument goes something like this: * 98% of all users don't give a damn about key validation, would much rather be vulnerable to an attack perpetrated by their provider, or the other party's provider, than to ever be bothered with confusing questions of key validity or to be unable to communicate for any period of time (since, in real life, keys can change in suspicious ways under normal usage). * For the 2% that does give a damn, it is a lot easier (and likely more secure) to just put the responsibility on them (rather than the key owner), instead of building building a complex infrastructure just for this 2%. What would a simple thing look like for email? It could have a few simple rules: (1) The client should use whatever latest key is advertised inline via headers in email it receives. Ideally, this would be validated by the provider via a very simple mechanism (such as grab user Bob's key from this well-known https URL). (2) To cold start, Alice can grab Bob's key via this well-known URL. Done. Super simple, relies on provider endorsement and CA system, but so what. If Alice is in the 2% that gives a damn, she can ask Bob, out of band, what his fingerprint is, and choose to not accept just any new key that comes along, although by doing so Alice is likely to not be able to talk with Bob a lot of the time. There are still a few edge cases. Alice might email Bob using a key for Bob that he no longer uses. Should the provider bounce the email to let Alice know? Or should Alice ask the provider if the key is still valid every time she sends a message to Bob (or once a day)? My objection to the "simple thing" is that, if I am Bob, I eventually want the ability to say, "I don't care if the other party is in the 2% that gives a damn or not, because I care, and I would rather that people cannot communicate with me than for any of my communication to be compromised". The argument against this is that any system that supported this would have horrible usability, because as Bob I would be potentially forcing complicated key failure states on anyone who communicates with me, even if they have already decided they don't want to deal with this kind of shit. This is a good point, but it still makes me uncomfortable. In the spirit of the incremental key validation rules I previously posted (https://pad.riseup.net/p/key-validation), I feel like it should be possible to start with the simple thing but to also allow for the complex thing if both parties support it. As written, this scheme for incremental key validation would do the 'simple thing' in cases where keys do not have expiration dates. -elijah _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
