[Catalog-sig] RubyGems Threat Model and Requirements

Wed Feb 13 03:12:42 CET 2013

Il giorno 12/feb/2013, alle ore 21:07, Daniel Holth <dholth at gmail.com> ha scritto:

> On Tue, Feb 12, 2013 at 2:20 PM, holger krekel <holger at merlinux.eu> wrote:
> On Tue, Feb 12, 2013 at 12:44 -0500, Daniel Holth wrote:
> > On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <rasky at develer.com> wrote:
> > > >
> > > > Your Task #6/#7 (related to PyPI generating the trust file, and pip
> > > > verifying it) are the ones where I think the input of the TUF team
> > > > will be most valuable, as well as potentially the folks responding to
> > > > the rubygems.org attack.
> > >
> > > My undestanding is that #6/#7 are not currently covered by TUF. So yes, I
> > > would surely value their input to review my design, evolve it together or
> > > scratch it and come up with something new.
> > >
> > > Sorry for the repetition, but I also volunteer for implementation. I don't
> > > mind if someone else does it (or a subset of it, or we split, etc.), but I
> > > think it is important to say that this is not a theoretical proposal that
> > > someone else will have to tackle, but I'm happy to submit patches (all of
> > > them, in the worst case) to the respective maintainers and rework them
> > > until they are acceptable.
> > >
> > > > The rubygems.org will also be looking at server side incident response
> > > > - I suspect a lot of that side of things will end up running through
> > > > the PSF infrastructure team moreso than catalog-sig (although it may
> > > > end up here if it involves PyPI code changes.
> > >
> > >
> > > While I do have some ideas, I don't think I'm fully qualified for that
> > > side of things. Primarily, my proposal helps by not forcing PyPI to handle
> > > an online "master" signing key with all the required efforts (migration,
> > > rotation, mirroring, threat responses, mitigations, etc.). If you read it,
> > > you had seen that PyPI is only required to validate signature (like pip),
> > > not sign anything.
> > >
> >
> > The alternative is to just use a system implemented by several PhD
> > [candidates?] in 2010 based on years of update system experience, before
> > pypi security was cool. A doc from last week is a hard sell.
> 
> For one, not all PHDs follow clean implementation and automated testing
> principles.  Secondly, I appreciate Giovanni's input, work, and his offer
> to help with implementation.  Let's not be too quick to dismiss it.
> On a funny sidenote, he is the only one with a successfully openssl-verified
> email in these security related email threads, just saying :)
> 
> best,
> holger
> 
> Well as someone whose own very similar scheme has been brutally rejected I should know better. My initial reaction was that GPG sucks and no one wants to use it. Reading the document you aren't really using GPG's signature "web of trust" feature. Instead, pypi maintains a well-known mapping of keys to packages and serves it over HTTPS.

Yes, that's correct. GPG chain-of-trust concept is not used in my proposal, because I don't think it would be a good fit for this problem given its requirements. Specifically, I believe pip users should not be bothered with useless click-through questions for each new package they install, which is what you would get far too often in case chain-of-trust were used.

> I don't see much difference between doing GPG and HTTPS versus running your own CA and having pypi do some other kind of online signing of the trust file. In the CA model the signature would just include the complete and recently signed keys chaining all the way back up to the (potentially offline) master key(s) and there would not be separate key retrieval traffic. Perhaps there would be a second server for key revocation apart from disassociating a key's permission to sign any particular package.
> 
> I like online trust! You can send the server a challenge and get a response about what is permitted -right-now- rather than at some time in the past. If the key -> package trust is secured by HTTPS you are doing online trust anyway, why not embrace it.

The problem with this suggestion is that you're not authenticating the packages end-to-end (from user to developer), that is you're fully trusting PyPI and/or an external CDN not to be compromised. I understand from your previous mail that you consider this not to be a problem. On the other hand, this answers your question: my design handles an attack that compromises PyPI at the file server level (or any of the mirror/CDN that simply host a copy of the files); users that manually hand-edit / maintain the trust file don't even need to worry about full PyPI compromisation.

So, if we decide that PyPI compromisation should be taken off the threat model, then we don't need GPG; in fact we wouldn't need *anything* on top of a HTTPS transfer (maybe just a simple checksum). But if you think of it, this is a strict subset of what my proposal offers. If you fully trust PyPI and for some reason don't want to use GPG at all (= don't want to let pip use GPG for you), then you will be able to simply specify --no-signature-checks or something like that.

> Wheel had the same idea of Giovanni's document of transmitting singly-signed or https-secured lists of package[key] mappings, but with elliptic curve cryptography and bare, short 256-bit keys there was never any indirect referencing of keys; the complete trusted public key was included.

Yes, this is the same design adopted by Bernstein for DNSCurve. The full public key (which is short, thanks to ECC) is embedded in the metadata being transmitted (in the case of DNSCurve, the DNS hostname), so that you already have the required information to validate the signature, without a further request.

In fact, I pondered this design a little for my proposal as well. Eventually, I decided to scratch it because:

* Installations of a Python package are usually not really performance sensitive (IOW, there is no specific performance requirement). Additional network requests to download GPG keys aren't a big problem.
* ECC has been added in GPG only in 2010. I wouldn't want to find out that it's not complete on all platforms and/or that, in some situation, on some server with old distributions, it is complicated to install such a relatively new GPG. BTW: GPG is still needed because there are a few good properties, compared to a in-house solution: standard signature files that can be checked with standard tools, standard key revocation process, standard keychain handling with correct security and per-platform safe passphrase handling, etc.
* There's lots of discussion about ECC patents, especially in USA. PSF is an US entity. I don't want it to ever be a problem, and I am not in the position to evaluate the situation (IANAL).

I hope my answers help you further understand my proposal.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130213/29febc61/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130213/29febc61/attachment-0001.bin>