[messaging] The Simple Thing

[elijah]

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