Hello from the TUF team

[Trishank Karthik Kuppusamy]

Hello rubygems,

We hear from Donald Stufft at the Python Catalog-SIG mailing list that
you are interested in securing rubygems.

We are The Update Framework (TUF) project
[https://www.updateframework.com/], and we would like to help Ruby and
Python folks to help secure their package managers.

TUF is a framework designed by computer scientists from NYU-Poly,
University of Washington and the Tor project to help solve some of the
more common problems with securing software updaters.

Here are some papers we wrote on the subject:

https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf
https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf

What we would like to do is to help the rubygems community to understand
how you may use TUF to secure your package manager with security
designed carefully and intrinsically, so that you do not have to worry
about the most common security issues.

Donald, havenwood and raggi introduced us to the Rubygems Trust Model
document [http://goo.gl/ybFIO], and we will comment on it as soon as we
find the time. In fact, we are going to have a TUF hackathon here in a
few hours, and we hope to make more progress on these matters soon enough.

Please feel free to reach out to us with your questions!

Thanks,
Trishank

_______________________________________________
RubyGems-Developers mailing list
http://rubyforge.org/projects/rubygems
RubyGems-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

[James Tucker]

Trishank,

Thank you for stopping by and offering your assistance, I really appreciate
it.

I have been digesting the Survivable Key Compromise paper, spec and
implementation, and it very much maps to my major concerns for the Rubygems
system; it is so far the first proposal I have seen that appears to be
close to complete.

I still need more time to digest everything fully, but in the meantime I
have some questions already (some of which may be born of
misunderstandings, so your patience is appreciated):

* What are your recommendations for the targets/* topology?
- If we use simply gem names (not full name-version-platform tuples or
strings), then I think the revocation model requires a rewrite of a whole
target metadata be rewritten after target key compromise. This may be
acceptable, however,
- If we use targets/gemname/version-platform then we can rewrite
targets/gemname.txt to disallow future publishing using compromised keys,
but existing (non-malicious) gemname/version-platform.txt remain valid. Is
this the case, and is this safe? (assuming all other standard roles)
- The paper loosely suggests in the language having these map to files,
which makes sense, but is somewhere between the above two options, and
requires new targets to be issued regularly (maybe that is a good thing?).
- There are some scaling concerns with each different approach that we
may need to consider. In any of the latter cases, release.txt will continue
to grow fast, although gzip and such will also continue to work well. At
some point though, parsing becomes slow and/or memory intensive.
* The paper mentions the metadata files for 8000 PyPI binaries reaching
several megabytes. We have considerably more data than this, as such we may
very much need to alter both the data format, and possibly slice the files
into pieces. Do you have any particular recommendations in this area? Are
there non-obvious key security considerations here (I think most are
covered by timestamp.txt and release.txt)?
* Given the existence of the release and higher level targets roles in
this system, do you still strongly recommend leaf-targets (e.g.
targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a
compromise of the rails key that signed it (in the event of t=1)?
* There is scope in the metadata, for two roles to have the same paths or
path patterns. Is it recommended such an event be a validation error?

Many thanks,

James



On 15 February 2013 00:39, Trishank Karthik Kuppusamy <

tk...@students.poly.edu> wrote:

> Hello rubygems,
>
> We hear from Donald Stufft at the Python Catalog-SIG mailing list that you
> are interested in securing rubygems.
>

> We are The Update Framework (TUF) project [https://www.updateframework.**
> com/ <https://www.updateframework.com/>], and we would like to help Ruby

> and Python folks to help secure their package managers.
>
> TUF is a framework designed by computer scientists from NYU-Poly,
> University of Washington and the Tor project to help solve some of the more
> common problems with securing software updaters.
>
> Here are some papers we wrote on the subject:
>

> https://isis.poly.edu/~**jcappos/papers/cappos_mirror_**ccs_08.pdf<https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf>
> https://isis.poly.edu/~**jcappos/papers/samuel_tuf_ccs_**2010.pdf<https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf>

>
> What we would like to do is to help the rubygems community to understand
> how you may use TUF to secure your package manager with security designed
> carefully and intrinsically, so that you do not have to worry about the
> most common security issues.
>
> Donald, havenwood and raggi introduced us to the Rubygems Trust Model
> document [http://goo.gl/ybFIO], and we will comment on it as soon as we
> find the time. In fact, we are going to have a TUF hackathon here in a few
> hours, and we hope to make more progress on these matters soon enough.
>
> Please feel free to reach out to us with your questions!
>
> Thanks,
> Trishank
>

> ______________________________**_________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/**rubygems<http://rubyforge.org/projects/rubygems>
> RubyGems-Developers@rubyforge.**org <RubyGems-...@rubyforge.org>
> http://rubyforge.org/mailman/**listinfo/rubygems-developers<http://rubyforge.org/mailman/listinfo/rubygems-developers>

[Trishank Karthik Kuppusamy]

Hello James,

Thanks very much for your email. I just realized that I forgot to copy
my advisor and one of the primary designers of the TUF framework, Prof.
Justin Cappos.

We are currently under some intense deadlines, but we will strive to get
back to you as soon as possible. Thanks in advance for your patience!

With best regards,
Trishank

[Justin Cappos]

Just to be a little more specific on our timeline, we have some grant
deadlines and paper deadlines all coming up on Thursday of next week.
We'll try to get back to you with answers after that. You're asking a lot
of good questions that I can't necessarily give off-the-cuff answers to.
I need to take time and really digest Ruby's use case and think through my
answers.

Sorry for the delay!

Thanks,
Justin


On Fri, Feb 15, 2013 at 7:42 PM, Trishank Karthik Kuppusamy <

[Justin Cappos]

Okay, thank you for being patient. My deadlines passed last night and I'm
starting to dig out...

* What are your recommendations for the targets/* topology?
> - If we use simply gem names (not full name-version-platform tuples or
> strings), then I think the revocation model requires a rewrite of a whole
> target metadata be rewritten after target key compromise. This may be
> acceptable, however,
>

Yes, you may need to do this in this case. In our thinking, a targets
role would map to a project. So the root would end up revoking a key from
a specific target and the list of trusted target keys would change. If
I'm the developer of a different target, my key / targets.txt does not need
to change.

> - If we use targets/gemname/version-platform then we can rewrite
> targets/gemname.txt to disallow future publishing using compromised keys,
> but existing (non-malicious) gemname/version-platform.txt remain valid. Is
> this the case, and is this safe? (assuming all other standard roles)
>

I suppose you could try to do things in this way (I don't know if it is
safe). However, I think the more natural way to do what you want to do is
make it so that older packages (only) are still trusted even if the key is
later compromised.

Instead, I would recommend revoking the compromised targets key and then
signing the old packages with the new key. (Apologies if I'm
misunderstanding this.)

> - The paper loosely suggests in the language having these map to files,
> which makes sense, but is somewhere between the above two options, and
> requires new targets to be issued regularly (maybe that is a good thing?).
>

You can require targets to be reissued using TUF by setting expirations
appropriately. Short expiration would require these keys to be online (or
close to it). If you do this, you're trading timeliness (how long can
someone get told an old version is current) for risk (how easy is it for
someone to steal your key).

> - There are some scaling concerns with each different approach that we
> may need to consider. In any of the latter cases, release.txt will continue
> to grow fast, although gzip and such will also continue to work well. At
> some point though, parsing becomes slow and/or memory intensive.

* The paper mentions the metadata files for 8000 PyPI binaries reaching
> several megabytes. We have considerably more data than this, as such we may
> very much need to alter both the data format, and possibly slice the files
> into pieces. Do you have any particular recommendations in this area? Are
> there non-obvious key security considerations here (I think most are
> covered by timestamp.txt and release.txt)?
>

You can split things up via delegating trust. There isn't just one
targets file which will simplify this tremendously.

> * Given the existence of the release and higher level targets roles in
> this system, do you still strongly recommend leaf-targets (e.g.
> targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a
> compromise of the rails key that signed it (in the event of t=1)?
>

yes, absolutely. If compromise means that someone else has the rails key,
they can act as a MITM for anyone getting updates and compromise all users
that retrieve the package. Compromises should be rare, or at least much
rarer than normal updates, so this shouldn't be a major performance or
scalability worry.

> * There is scope in the metadata, for two roles to have the same paths or
> path patterns. Is it recommended such an event be a validation error?
>

Is there a reason why you would logically want this to occur? I would say
that it seems both potentially useful and suspicious. Raising an error,
but having a flag to override and continue may make sense. (I'm just
pulling this out of the air though.)

In the next week or so, we can get a setup together where you can play more
with TUF and see how it works in different scenarios yourselves. We're
starting to get into discussion with the PyPI folks too so our time is a
little divided, but we'll do what we can to show you what a realistic
deployment might look like.

Thanks,
Justin
P.S. If you'd like to open your google doc for comments, I have a few
other things I could mention there.