[messaging] The Simple Thing

[Tao Effect]

On Sep 24, 2014, at 3:29 PM, elijah <elijah at riseup.net> wrote:

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


OK, but you've glossed over all the details and then declared it to be simple.

We already have "the simple thing":

https://gpgtools.org

To cold start, you search for their email, and this could be automated.

The problem is that oftentimes you get back multiple results and aren't sure what is the right one.

So then we have this "well-known URL" suggestion.

Well what would that be? It would be, I think, a centralized service like Gmail. We can't expect the 98% to run their own servers and setup their own URLs and whatnot.

So, unless I'm missing something, to me it seems like your simple thing leads to a handful of giant entities managing the public keys for 98% of people.

A bow to centralization, and for no reason, as it doesn't seem to give any advantage over the blockchain (in practical use cases).

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


What exactly does the simple thing do then to differentiate itself from how email would work with the blockchain?

The Blockchain *is* the simple thing.

Here's how email would work with the blockchain (once software matures):

To send someone an email:

1) Enter their email address.
2) Type message and click send.

Done. And the correct key is fetched from the blockchain based on their email.

To receive an email:

1) Receive an email.

Done.

To reply to an email.

1) See "to send someone an email".


It is simple, but it is also secure.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Sep 24, 2014, at 3:29 PM, elijah <elijah at riseup.net> wrote:

> 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
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140924/afe977c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140924/afe977c1/attachment.sig>