[Catalog-sig] RubyGems Threat Model and Requirements

[Daniel Holth]

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.

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.

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. There was also no concept of certificate chains or trust
delegation. Although technically worse it may have been able to be used,
implemented and understood profitably without understanding concepts such
as DER encoding etc.

Not cryptographically-provably yours,

Daniel Holth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130212/2246f612/attachment-0001.html>