<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;">Hi Trevor,<div><br></div><div>We met at SOUPS 2014 and I asked you for your thoughts on DNSChain / Namecoin / Blockchains / etc.</div><div><br></div><div>Your response then was that you didn't know because you hadn't looked into it.</div><div><br></div><div>Therefore, I found this email of yours quite puzzling, as it contains no mention of what seems to be the answer you're looking for: <b>the blockchain.</b></div><div><br></div><div>I believe it is a near-perfect solution to the problems you are outlining, and therefore invite you to read the README:</div><div><br></div><div><a href="https://github.com/okTurtles/dnschain/blob/master/README.md">https://github.com/okTurtles/dnschain/blob/master/README.md</a></div><div><br></div><div>If you have any concerns about it, I'll do my best to address them.</div><div><br></div><div>Sincerely,</div><div><br></div><div>Greg Slepak</div><div>okTurtles Foundation</div><div><br></div><div><div apple-content-edited="true"><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 Aug 18, 2014, at 2:09 AM, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Suppose you want to lookup someone's public key based on their<br>username (e.g. lookup a PGP key based on email address).<br><br>Once you have this key you can do TOFU, fingerprint checks, etc., but<br>you'd ALSO like to have some trustworthy entity tell you the key. But<br>how?<br><br> * Search the "web of trust" of people you know, and people they know,<br>and so on, hoping there's a path to someone who can vouch for the<br>subject's key. But this involves a public social graph of users,<br>expensive graph searching, and poorly-understood human interface<br>issues around graphs of trust.<br><br> * Query a "central authority" where everyone registers their public<br>key. To mitigate availability and monopoly risk there could be<br>several such authorities, and users just have to register with one.<br>But multiple authorities increases the risk of "misissuance", and<br>mitigating that risk is difficult. (One approach is for authorities<br>to also provide a proof that the key was published (Certificate<br>Transparency), so misissuance can be detected and responded to.<br>That's promising, but complicated and unproven.)<br><br>The "trust agility" in the web of trust seems like a good idea for any<br>system without the performance constraints of HTTPS. But using<br>regular people as trust intermediaries seems unlikely to scale outside<br>small groups. So we could combine these: Bob could register his<br>public key with several keyservers, and Alice could query several<br>keyservers she trusts. Hopefully there's overlap and Alice finds<br>Bob's key.<br><br>But there's still a coordination problem - what if Bob registers his<br>key someplace, and Alice checks somewhere else? It's unclear how this<br>would play out at scale - fragment into islands? centralize around one<br>authority? Maybe Bob registers his public key with a central,<br>widely-known keyserver and also local keyservers based on his<br>affiliations, but that's a lot of registering, and a lot of keyservers<br>that's it's unclear why anyone would run.<br><br>---<br><br>A different approach is to have Bob's service provider, as specified<br>in his username, be his keyserver (LEAP, STEED, UEE). For example,<br>the keyserver for <a href="mailto:bob@example.com">bob@example.com</a> would be <a href="http://example.com">example.com</a>. This<br>eliminates the coordination problem, makes registration easier (Bob<br>authenticates to his provider), *might* address the incentive problem<br>(Bob's service provider would run the keyserver as part of providing<br>him service), and gives Bob flexibility to choose the keyserver (by<br>choosing his provider).<br><br>Of course, now Alice needs to authenticate <a href="http://example.com">example.com</a>. A DNS<br>solution (DNSSEC or DNSCurve) seems elegant - if <a href="mailto:bob@example.com">bob@example.com</a> is<br>vouched for by <a href="http://example.com">example.com</a>, then <a href="http://example.com">example.com</a> could be vouched for by<br>com, who's vouched for by the DNS root. But since <a href="http://example.com">example.com</a> is a<br>public server with administrators, it has plenty of other options<br>(HTTPS certs, CT logs, pinning via HPKP/TACK or curated pin lists,<br>etc.). So we can handwave "Alice authenticates <a href="http://example.com">example.com</a>" as being<br>solvable a bunch of ways.<br><br>A sharper criticism is that changing providers and usernames is<br>costly, so Bob's flexibility is limited. Moreover, Bob's provider is<br>on the communication path, thus is one of the most important threats<br>for end-to-end crypto to protect against.<br><br>So provider-based keyservers are convenient (easy for Bob to register<br>with and Alice to find), but it's unclear how much they should be<br>trusted. Maybe they aren't trustworthy but are useful anyways, to<br>find keys we acquire trust in via TOFU and fingerprint checks.<br><br>Or maybe keyservers could be made more trustworthy via auditing. If<br>keyservers support lookup over Tor then it's hard for them to deliver<br>targeted wrong answers. Keyservers could also support "transparency"<br>similar to CT, e.g. periodically snapshot their directory so that<br>3rd-party monitors can fetch the delta of new/deleted entries. These<br>monitors could notify Bob if his key changes, and send Alice a root<br>hash that she uses to check that keyserver responses have been<br>published [1].<br><br>So far we've assumed Bob has a single username. But Alice might know<br>Bob via multiple usernames (email, skype, facebook, twitter, etc). If<br>all these hosted keyservers, Alice could lookup Bob's public key from<br>multiple providers. Even if they don't host keyservers, social media<br>sites make it easy for Bob to publish information, so could be<br>leveraged as "keyservers" with some cleverness (see Keybase [2]).<br><br>---<br><br>In conclusion, there's a lot of ways to distribute keys. We probably<br>want more and better keyservers. It's hard to say who should run<br>these. Maybe existing service providers will help, or can be<br>leveraged regardless - that's worth discussing more.<br><br>There are also protocol design questions that could be tackled<br>independent of who runs things, e.g.<br> * How to make keyservers auditable<br> * Design of protocols and data formats so that public keys, certs,<br>fingerprints, revocation data, prekeys, and so on can be published<br>through a variety of channels<br><br>Probably more but this is way too long already...<br><br>Anyways, thoughts?<br><br><br>Trevor<br><br>[1]<br><a href="https://moderncrypto.org/mail-archive/messaging/2014/000226.html">https://moderncrypto.org/mail-archive/messaging/2014/000226.html</a><br>https://moderncrypto.org/mail-archive/messaging/2014/000244.html<br><br>[2] https://keybase.io/<br>_______________________________________________<br>Messaging mailing list<br>Messaging@moderncrypto.org<br>https://moderncrypto.org/mailman/listinfo/messaging<br></blockquote></div><br></div></body></html>