<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>On Sep 24, 2014, at 3:29 PM, elijah <<a href="mailto:elijah@riseup.net">elijah@riseup.net</a>> wrote:</div><div><br></div><div><blockquote type="cite">What would a simple thing look like for email? It could have a few<br>simple rules:<br><br>(1) The client should use whatever latest key is advertised inline via<br>headers in email it receives. Ideally, this would be validated by the<br>provider via a very simple mechanism (such as grab user Bob's key from<br>this well-known https URL).<br><br>(2) To cold start, Alice can grab Bob's key via this well-known URL.<br></blockquote></div><div><br></div><div><div>OK, but you've glossed over all the details and then declared it to be simple.</div><div><br></div><div>We already have "the simple thing":</div><div><br></div><div><a href="https://gpgtools.org">https://gpgtools.org</a></div><div><br></div><div>To cold start, you search for their email, and this could be automated.</div><div><br></div><div>The problem is that oftentimes you get back multiple results and aren't sure what is the right one.</div><div><br></div><div>So then we have this "well-known URL" suggestion.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>A bow to centralization, and for no reason, as it doesn't seem to give any advantage over the blockchain (in practical use cases).</div><div><br></div><div><blockquote type="cite">All the schemes that have been proposed, such as nyms, DIME, PPE,<br>nicknym, logs, blockchains, etc, are predicated on the idea that Bob<br>ultimately is the one who knows what his key is and the onus should be<br>placed on Bob for ensuring that the key other people see (either in a<br>log or via key directories or dns or whatever) is the right key.</blockquote></div><div><br class="webkit-block-placeholder"></div><div>What exactly does the simple thing do then to differentiate itself from how email would work with the blockchain?</div><div><br></div><div>The Blockchain *is* the simple thing.</div><div><br></div><div>Here's how email would work with the blockchain (once software matures):</div><div><br></div><div>To send someone an email:</div><div><br></div><div>1) Enter their email address.</div><div>2) Type message and click send.</div><div><br></div><div>Done. And the correct key is fetched from the blockchain based on their email.</div><div><br></div><div>To receive an email:</div><div><br></div><div>1) Receive an email.</div><div><br></div><div>Done.</div><div><br></div><div>To reply to an email.</div><div><br></div><div>1) See "to send someone an email".</div><div><br></div><div><br></div><div>It is simple, but it is also secure.</div><div><br></div><div>- Greg</div><div> <br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;">--</span><br style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;">Please do not email me anything that you are not comfortable also sharing</span><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;"> with the NSA.</span> </div> <br><div><div>On Sep 24, 2014, at 3:29 PM, elijah <<a href="mailto:elijah@riseup.net">elijah@riseup.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Two weeks ago, many of the people on this list had the opportunity to<br>meet in person and discuss further this question of key validation.<br><br>During that conversation, Moxie elaborated what he means by "the simple<br>thing", as in "why not just do the simple thing for key validation?"<br><br>For me, the most important distinction that Moxie made between the<br>simple thing and the complex thing is this:<br><br>Bob has a public key and Alice wants to know if this key is the right one.<br><br>* The simple thing: Alice is responsible for key validation.<br>* The complex thing: Bob is responsible for key validation.<br><br>All the schemes that have been proposed, such as nyms, DIME, PPE,<br>nicknym, logs, blockchains, etc, are predicated on the idea that Bob<br>ultimately is the one who knows what his key is and the onus should be<br>placed on Bob for ensuring that the key other people see (either in a<br>log or via key directories or dns or whatever) is the right key.<br><br>If I recall correctly, Moxie's counter argument goes something like this:<br><br>* 98% of all users don't give a damn about key validation, would much<br>rather be vulnerable to an attack perpetrated by their provider, or the<br>other party's provider, than to ever be bothered with confusing<br>questions of key validity or to be unable to communicate for any period<br>of time (since, in real life, keys can change in suspicious ways under<br>normal usage).<br><br>* For the 2% that does give a damn, it is a lot easier (and likely more<br>secure) to just put the responsibility on them (rather than the key<br>owner), instead of building building a complex infrastructure just for<br>this 2%.<br><br>What would a simple thing look like for email? It could have a few<br>simple rules:<br><br>(1) The client should use whatever latest key is advertised inline via<br>headers in email it receives. Ideally, this would be validated by the<br>provider via a very simple mechanism (such as grab user Bob's key from<br>this well-known https URL).<br><br>(2) To cold start, Alice can grab Bob's key via this well-known URL.<br><br>Done. Super simple, relies on provider endorsement and CA system, but so<br>what. If Alice is in the 2% that gives a damn, she can ask Bob, out of<br>band, what his fingerprint is, and choose to not accept just any new key<br>that comes along, although by doing so Alice is likely to not be able to<br>talk with Bob a lot of the time.<br><br>There are still a few edge cases. Alice might email Bob using a key for<br>Bob that he no longer uses. Should the provider bounce the email to let<br>Alice know? Or should Alice ask the provider if the key is still valid<br>every time she sends a message to Bob (or once a day)?<br><br>My objection to the "simple thing" is that, if I am Bob, I eventually<br>want the ability to say, "I don't care if the other party is in the 2%<br>that gives a damn or not, because I care, and I would rather that people<br>cannot communicate with me than for any of my communication to be<br>compromised". The argument against this is that any system that<br>supported this would have horrible usability, because as Bob I would be<br>potentially forcing complicated key failure states on anyone who<br>communicates with me, even if they have already decided they don't want<br>to deal with this kind of shit.<br><br>This is a good point, but it still makes me uncomfortable. In the spirit<br>of the incremental key validation rules I previously posted<br>(<a href="https://pad.riseup.net/p/key-validation">https://pad.riseup.net/p/key-validation</a>), I feel like it should be<br>possible to start with the simple thing but to also allow for the<br>complex thing if both parties support it. As written, this scheme for<br>incremental key validation would do the 'simple thing' in cases where<br>keys do not have expiration dates.<br><br>-elijah<br>_______________________________________________<br>Messaging mailing list<br><a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>https://moderncrypto.org/mailman/listinfo/messaging<br></blockquote></div><br></div></body></html>