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