search

rubygems-trust / rubygems.org

The Ruby community's gem hosting service.
https://rubygems.org
MIT License
16 stars 2 forks source link

Key dissemination in a WoT system #16

Open tarcieri opened 11 years ago

tarcieri commented 11 years ago

Several proposals (e.g. #6, #10) propose a web of trust. From there, there's a bit of handwaving about companies like 37Signals and Github maintaining a trusted keyring that users can bootstrap their web of trust from.

I'd like more specific proposals to eliminate this handwaving. A proposal might look like this:

1) End user downloads RubyGems 2) End user finds a list of recommended organizations from which to obtain public keyrings (or at the very least, key fingerprints) 3) End user visits each of these sites individually, and obtains a keyring/fingerprint for that organization. We'll assume for the sake of argument that an attacker isn't able to compromise all these organizations at once (a silly assumption, but whatever) and that the organizations are using SSL to prevent MitM attacks 4) End user (somehow?) adds the "trusted" keyrings to RubyGems manually

tarcieri commented 11 years ago

Suppose I should mention this came out of the discussion in #8. As far as I'm concerned, unless this problem is solved, #8 (or a more diminished form thereof) is the only solution.

Perhaps people have creative solutions here and I don't want to diminish them. But unless you can solve this problem successfully in an unobtrusive way, a WoT is not really a usable system for your average human.

Note: I have spent several years researching this very problem and working on a solution and my general opinion is that is is unworkable for this particular use case. If you are legitimately interested in secure distributed web-of-trust systems, I strongly invite you to read the papers I cite in my Cryptosphere project (see "Suggested Reading")

Geal commented 11 years ago

The proposal you made (downloading from websites) is one of the easy ways to do it. Even if it is not perfect from a security point of view, it has mostly worked for a long time in other systems, because once the system distributing the public key is compromised, the issue is made public quickly when people see a signature by a different key.

Also, assuming that all of their servers could be compromised at the same time means that securely distribution any root key with the rubygems package can be compromised too. In both cases, it is possible, but a bit "handwavy".

Another solution would be to distribute the public keys for organisation right inside the rubygems package. The choice of root keys depends effectively on the rubygems maintainers and downstream distributors, but this problem is also present for the CA system.

Remember that my proposal (#10) is essentially a multiroot system. It is not a distributed trust system. Its main task is to warn people when one of the roots has been compromised. And it allows people to take over trust management for themselves, their company, ther friends, if they want or need to.

Distributing multiple roots (in browsers, in OS for code signing) has never been a real problem.

tarcieri commented 11 years ago

How do I put this delicately... security issues aside, isn't this a giant pain in everyone's ass?

Geal commented 11 years ago

Running a CA is a pain in the ass too, but one you seem willing to bear :)

tarcieri commented 11 years ago

Advantage of a CA is it's only a pain in one person's/one organization's ass, at least until the CA is compromised

nyarly commented 11 years ago

What would be the problem with distributing rubygems with a default (set of) keyring(s)? Encourage users to seek out other keys and rings to trust, and to verify the keys and rings they do trust.

Part of that effort would include getting various luminaries to include public, in person verifications of their fingerprints. "I'm DHH - this slide has the openssl command to check my public key in your rubygems install. Take a moment. Now, back to making fun of the French."

tarcieri commented 11 years ago

Whose keys should ship with RubyGems?

nyarly commented 11 years ago

Anyone who fits the following criteria:

Willing to be in the default set of keys - willing therefore to sign other keys, at a minimum. Willing to commit to a number of public appearances or conference visits to verify their keys. Preference given for reputation - both size and quality.

Find a suitable group of 3-10 members and name them the Ruby Trust Council. Thereafter, elevation to the council by vote, etc. To a certain degree, I like the fustiness of the "Trust Council" just because it'll drive some users to build their own separate webs.

tarcieri commented 11 years ago

How exactly is this different from a CA?

nyarly commented 11 years ago

Or vice versa :)

Specifically, because while there's a default authority, starting immediately after downloading Rubygems, users can split off onto their own trust chains, including trusting gems not yet certified by rubygems.org. Likewise, I might decide that even though both are in the default set, I trust tenderlove but not dhh. If there's enough heterogeneity in deployed trust policies, then corruption of keys ceases to be a nuclear event.

Ultimately, while the default set of signers would be related to the CA solution, the distinction would be that every user would be accepting the set, if only by tacit agreement with a default, rather than being compelled to accept the decisions of a single authority.

On Tue, Feb 19, 2013 at 1:41 PM, Tony Arcieri notifications@github.comwrote:

How exactly is this different from a CA?

— Reply to this email directly or view it on GitHubhttps://github.com/rubygems-trust/rubygems.org/issues/16#issuecomment-13801470.