Establishing trust in keybase itself and its binary releases

[nealmcb]

Please make it clearer, more robust and easier for a person who is new to keybase to establish their own trust in your keys and code. This is the crucial initial bootstrapping problem.

One requirement is ensuring that users don't have to trust your website, and their connection to it, completely as of the moment they try to install things. Because, of course, web sites are pretty easy to hack, and it is pretty easy to fool people about what they see on the web.

E.g. at Keybase - our public code-signing key I see just a few links of unclear helpfulness.

Simply once again telling us, from your own web site, that your key fingerprint is 222B 85B0 F90B E2D2 4CFE B93F 4748 4E50 656D 16C7 doesn't help with this bootstrapping of trust.

If you show people how to list the signatures on that key: gpg --list-sigs 656d16c7 (they may need to import it first?), and then looking for trust in those keys is one approach. One way to facilitate that would be providing a link to PGP key statistics : Chris Coyne - chris.at.chriscoyne.com which allows folks to trace paths of trust to one of the signers of the keybase key from some other key they trust (hopefully their own...). The other signing keys don't seem to be in the strong set which is necessary for use of that tool.

Another good approach would be to make it obvious how users can check keybase's own announcements of its own key and identity on a variety of other web sites and key repositories. Showing how to do that would provide a good introduction to the whole keybase security model, and demonstrate how it doesn't rely on trusting the keybase code itself.

Including an explanation of how to use gpg to get from the keys at https://keybase.io/.well-known/keybase.txt to keybase's own code-signing key would be a good start.

Beyond that it seems suspicious that I see nothing relevant e.g. at https://gist.github.com/keybase/ or https://twitter.com/search?q=%40keybaseio%20verifying%20myself&src=typd If there is a good reason for not announcing your own key there, please document it.

Other good approaches would be to link to publications of your key via dnssec (or even plain old dns) providing some sort of useful tie from the X.509 certificate world, and demonstrating compliance with HTTP Public Key Pinning and HTTP Strict Transport Security.

[nealmcb]

In addition, it's scary that your install instructions don't clarify how important it is for prospective users to properly establish trust in the code that they're about to run, and provide information (such as that above) on ways to do that. Instead you just tell people to run .exe files, or install raw .deb files or .dmg files.

Other approaches exist for specific platforms, e.g. providing a ppa for Ubuntu, or providing signed install packages for Mac or Windows via some of the existing technologies there. Ensuring that updates are automatically installed is typically a key step for trustable software.

Best would be eventually moving to a secure update approach, e.g. based on The Update Framework (TUF) | Like the S in HTTPS, a plug-and-play library for securing a software updater, which addresses update issues not addressed by any of the above.

[allthingsgo]

My OSX runs 10.9.5... and .dmg binary says 'version not supported'... is there any instruction to compile from source for this particular OSX version? thanks!

[cjb]

@nealmcb (I'm a Keybase employee, but not one of the founders, so this is mostly personal opinion.)

I think TLS and OS-level dev certificates (we use those) are the state of the art for the trust bootstrapping problem.

[cjb]

Oops, hadn't finished typing. Anyway, that's about the size of it. We already use a pinned cert distrusting the OS keystore for autoupdates. I don't think there's anything great we can do to bootstrap trust with most of our users that won't just scare them off. We're trying to do outreach past the crowd of people already using PGP.

(As you point out, simply advertising our key or signatures on our website isn't a real gain in trust, even though that's what most people familiar with PGP seem to ask for.)

[nealmcb]

I'm glad to hear about your use of pinning - thanks. Simply adding announcements of keybase to GitHub and Twitter, in case people go looking, shouldn't scare anyone off. Linking to them and/or explaining them would also seem significantly more positive than negative, though of course adding verbosity could be an issue, so it could be done in a separate page, as could the gpg explanations. Even just leaving this issue open provides some visibility of some existing out-of-band assurances that back up trust in keybase. And thanks for keybase - it is very helpful!