[Catalog-sig] RubyGems Threat Model and Requirements

[Giovanni Bajo]

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

> On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <rasky at develer.com> wrote:
> Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan <ncoghlan at gmail.com> ha scritto:
> 
> > On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo <rasky at develer.com> wrote:
> >> Hello Nick,
> >>
> >> I've added the initial Requirements and Thread Model section to my document. I've also added a section "Future scenarios" at the end of the document.
> >>
> >> I hope they complete what you were feeling was missing from the proposal.
> >
> > Thanks, that helps me a lot in understanding the overall goals of your
> > approach - in particular, it more clearly puts several things out of
> > scope :)
> >
> > 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. 

Sarcasm is not appreciated, but I got your point (= PhDs rule, you poor guy suck).

I think I've already elaborated on why TUF is just a subset of what we need for PyPI, so it's not useful to reiterate. I'm now looking forward to talk to Justin, when he is available.

> At first I didn't like the idea of pypi running a CA or an associated CA but I think it is a fantastic idea. There would be no key revocation or third-party keyservers, just up-to-date positive assertions (including necessary keying material) about whether a key was allowed to sign a particular package. The threshold signatures (n of m signatures required, both can be 1) feature is pretty mind-blowing as well.
> We should trust our servers. We already do for https, the keys are online, and it is a good thing. When pypi is hacked Martin will tell us and we can roll back to some earlier verifiable state.

All of the above benefits are present also with my design, that doesn't require an online signing key. *Especially* if you trust the server, those benefits are there (though not trusting the server is a basic part of the threat model of both TUF and 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/20130212/d6772bc9/attachment.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/20130212/d6772bc9/attachment.bin>