Signing the OPAM Repository: TUF Meets Git
opam.ocaml.org
Signing the OPAM Repository: TUF Meets Git
1–10 of 21 posts
Re: Signing the OPAM Repository: TUF Meets Git
#2I've recently become really interested in things around the periphery of secure systems keys etc.
For example in this scenario, what happens if one of key-holders dies? Presumably the remaining are enough for a quorum, but say something bad happens at a conference that many of them are at? It makes me think of why the President and Vice-president aren't in the same place at the same time.
In this case, I expect it would be possible to start again and select a new group of keyholders but what downstream effects would that have? In any case, I'm looking forward to seeing this progress.
(Incidentally, one of the contributors is also an author of the OCaml TLS stack.)
Re: Signing the OPAM Repository: TUF Meets Git
#3(Edit: I think it is great that we're working on signing software. I think that is very important, so important that I want to see it done right. So I have questions, in particular about TUF vs the more knee-jerk alternatives. But I would like to see signing, whether through TUF or the more well-known options.)
It seems that in order to add a new package or developer, a quorum of administrators must go to their secure signing machines and approve the key for that delegation. I don't see how that scales to active communities with lots of new developers.
Despite that administrative work and delay, it doesn't seem that the end result offers any guarantees about the repository other than that files haven't been tampered with. The repositories can still include malicious people or malicious software, because the administrators aren't doing any form of validation.
I also wonder what happens if people start squatting names and how the administrators will determine who has the legitimate claim to names.
This feels very similar to the CA system, except that we have pinned a particular CA (our "trusted administrators"). We have to compare that to choosing a CA (e.g. LetsEncrypt.org) and requiring that all keys be signed by that. I'm no fan of the CA system, but it does seem that the CA system (with pinning) is more tested, and has already implemented stronger procedures and guarantees than what we are getting here.
The timestamp signing system is nice, in that it allows for easy mirroring without requiring TLS. Given the timestamp signing key is online, it does seem we could more easily just serve the timestamp file from a central server though, over https, and then allow everything else to be mirrored (the https://security.debian.org model, I believe)
Re: Signing the OPAM Repository: TUF Meets Git
#4I've recently become really interested in things around the periphery of secure systems keys etc. For example in this scenario, what happens if one of key-holders dies? Presumably the remaining are enough for a quorum, but say something bad happens at a conference that many of them are at? It makes me think of why the President and Vice-president aren't in the same place at the same time. In this case, I expect it wo…
The quorum definitively helps. If too few keys/people are remaining, there are two options: download and install an updated opam (with a new set of keys) out of band OR using another opam-repository (with e.g. trust-on-first-use) for an update of opam itself (which then ships new keys for the main opam repository).
Re: Signing the OPAM Repository: TUF Meets Git
#5For those who are interested in following the discussion that the maintainers/devs are having, you'll find it starting at:
http://lists.ocaml.org/pipermail/platform/2015-June/000595.h...
Re: Signing the OPAM Repository: TUF Meets Git
#6(Edit: I think it is great that we're working on signing software. I think that is very important, so important that I want to see it done right. So I have questions, in particular about TUF vs the more knee-jerk alternatives. But I would like to see signing, whether through TUF or the more well-known options.) It seems that in order to add a new package or developer, a quorum of administrators must go to their secur…
Not at all: adding new packages or developers is automatically signed (by the snapshot bot). Administrators may later sign the keys and delegations, individually or in batch, after verifying the developer identity out of band (the specification doesn't yet include the mechanisms for this verification, but with a git repo based on GitHub, the GitHub login gives a good start).
Re: Signing the OPAM Repository: TUF Meets Git
#7(Edit: I think it is great that we're working on signing software. I think that is very important, so important that I want to see it done right. So I have questions, in particular about TUF vs the more knee-jerk alternatives. But I would like to see signing, whether through TUF or the more well-known options.) It seems that in order to add a new package or developer, a quorum of administrators must go to their secur…
You should briefly think how opam does updates currently: a repository on GitHub where developers submit their pull requests. This won't change too much.
Guarantees are: if a new package from a new developer is submitted, basically none. The signing of delegation and developer keys (by repository maintainers) enables a web-of-trust style system: once package `foo` has been claimed by the well-known (and signed) developer `alice`, there's no way that `eve` will successfully update `foo` (without getting `alice` key, and also then need to go via GitHub and repository maintainers).
Re: Signing the OPAM Repository: TUF Meets Git
#8(Edit: I think it is great that we're working on signing software. I think that is very important, so important that I want to see it done right. So I have questions, in particular about TUF vs the more knee-jerk alternatives. But I would like to see signing, whether through TUF or the more well-known options.) It seems that in order to add a new package or developer, a quorum of administrators must go to their secur…
I cannot follow your claim "stronger procedures and guarantees than what we are getting here". CAs might be useful for a single resource, but we have here a bag of packages and want to distribute the whole repository (with end-to-end signatures). Also, please read the TUF paper and specification which elaborates on the motivation.
And serving sth over http/s and the repository out-of-band opens possible attacks - that's why we decided on a single connection. Git gives us already some linearity/monotonicity conditions.
Re: Signing the OPAM Repository: TUF Meets Git
#9(Edit: I think it is great that we're working on signing software. I think that is very important, so important that I want to see it done right. So I have questions, in particular about TUF vs the more knee-jerk alternatives. But I would like to see signing, whether through TUF or the more well-known options.) It seems that in order to add a new package or developer, a quorum of administrators must go to their secur…
I cannot follow your claim "stronger procedures and guarantees than what we are getting here". CAs might be useful for a single resource, but we have here a bag of packages and want to distribute the whole repository (with end-to-end signatures). Also, please read the TUF paper and specification which elaborates on the motivation. And serving sth over http/s and the repository out-of-band opens possible attacks - tha…
The fundamental problem here is signing keys as authoritative over subsets of a namespace (I believe). CAs are pretty good at that, so we should compare TUF to the CA system (with pinning). In practice, that means that you have to get a certificate for your package, which also requires a DNS name and SSL hosting. You could also use the PKI infrastructure, but only to sign the packages, and not require TLS. If you wanted to eliminate the cost requirements, you could offer subdomains of opam.ocaml.org, (and make sure that your CA would sign sub-sub-domains). But then you're taking on the burden of allocating those subdomains.
My fear is that even allocating subdomains of opam.ocaml.org is a tough problem in the real world. And you're not only doing (the equivalent of) that, you're also running an alternative CA, with alternative signing software. I wish you success, but this seems ambitious.
In contrast, we know the CA/https system works and we know its failings (in particular the evil CA attacks, mostly fixed by pinning). That system is highly distributed and needs no custom software. It also needs little extra work, which is always a good thing.
I've looked at the TUF papers. Can you elaborate on the attack you're describing? They don't seem to compare TUF to alternatives (that I could find). (Edit: and to be clear, my straw-man here is serving the initial git revision information over HTTPS, fetching the hashed data over HTTP & mirrors, and then verifying the hash)
Re: Signing the OPAM Repository: TUF Meets Git
#10(Edit: I think it is great that we're working on signing software. I think that is very important, so important that I want to see it done right. So I have questions, in particular about TUF vs the more knee-jerk alternatives. But I would like to see signing, whether through TUF or the more well-known options.) It seems that in order to add a new package or developer, a quorum of administrators must go to their secur…
Not at all: adding new packages or developers is automatically signed (by the snapshot bot). Administrators may later sign the keys and delegations, individually or in batch, after verifying the developer identity out of band (the specification doesn't yet include the mechanisms for this verification, but with a git repo based on GitHub, the GitHub login gives a good start).
Thank you for the clarification. Can I install these "not yet trusted" packages? Presumably I can, I just get a big warning. And how do you deal with squatters - can I (as the "real developer") submit a second claim on an unverified package name (that an impostor has claimed)?
Edit: And does this mean that the snapshot bot automatically merges (well-formed) pull requests for new packages?