Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Federation #162

Open
tomlowenthal opened this issue Mar 7, 2014 · 5 comments

Comments

@tomlowenthal
Copy link

commented Mar 7, 2014

As long as Keybase is a single source of authority, it's a target for attack and coercion. That's a problem. Like SKS, email, Jabber, or any other large-scale piece of infrastructure, Keybase should federate.

This means that anyone should be able to run a Keybase server and have it be just as authoritative as the one at <keybase.io>. When someone uploads new or changed info to any keybase server, it should sensibly propagate between them.

This requires design changes. Right now, Keybase (presumably) stores a bunch of user-related data in an unauthenticated database. Keybase has user accounts, where Keybase authenticates users to allow them to change things. These are dangerous design features, but they can all be fixed.

@elijh

This comment has been minimized.

Copy link

commented Mar 7, 2014

It seems to me that keybase needs some clarity of purpose. Although mostly about discovery, keybase is implicitly stepping into the murky waters of key binding--the process of binding a human memorable identifier to a cryptographic key.

The existing methods of binding, Certificate Authorities and the Web of Trust, have both become recently discredited. So, it makes a lot of sense to experiment with new approaches.

There are numerous possible approaches. For example, CA system, TOFU, WoT, DNSSEC, Mail-back, network perspective, global append-only log, to name a few.

The method by which keybase supports external identity proofs can be reduced to trusting the CA system, albeit hedged by allowing multiple proofs from different domains. However, since keybase is centralized, it makes for a single target to direct any X.509 attacks against.

It is 2014. We can, and must, do better. There are a lot of ideas floating around for how to better address the binding problem. If federated, keybase could adopt a model similar to that used by Nicknym, where federated servers provide key binding services through a combination of TOFU, network perspective, and key endorsement.

@cxxr

This comment has been minimized.

Copy link

commented Mar 7, 2014

How is what you're suggesting different than current PGP key servers? I guess they don't currently propagate keys, but that gets complicated around the edges. What do you do if two servers get two keys for the same email address at the same time?

Federation and decentralization can cause just as many problems as they solve, so we need to think carefully about what problems we're solving and what problems we've decided to not solve.

@tomlowenthal

This comment has been minimized.

Copy link
Author

commented Mar 8, 2014

@cxxr Keyservers do currently propagate keys. They don't check UIDs. If two keys have the same UID, they host both and users get to decide. In Keybase's case that should be simple: which key has a proof for the Twitter account I know?

@elijh

This comment has been minimized.

Copy link

commented Mar 8, 2014

What do you do if two servers get two keys for the same email address at the same time?

each server is authoritative for a particular identifier so a conflict would mean an attack has been detected. servers update keys from other servers based on a strict ruleset.

keyservers were designed to facilitate WoT. they are good for that, but not good for binding.

@bgpugh

This comment has been minimized.

Copy link

commented Apr 6, 2014

I think having keybase's verification methods as manually-auditable as they are goes a long way to solving this. I don't see anything stopping anyone from starting up a secondary service that posts verification blobs in the same format/method as keybase or even verifying keybase's gists/tweets themselves for their users (we trust that this is Alice using keybase, as demonstrated by <proof url>)

Is there any reason keybase would be averse to recognizing the same proof blobs from other services? The signature of the object proves key ownership and the content of the signed object gives an identity URL (object[body][key][host] + object[body][key][username] or object[body][key][host] + object[body][key][fingerprint]) that you could use to request confirmation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.