bug#22883: Discussion of TUF in the context of Git checkout authentication

[ludo@gnu.org (Ludovic Courtès)]

[-- Attachment #1: Type: text/plain, Size: 6658 bytes --]

Hello!

Here are some (somewhat unstructured!) thoughts about what it means to
deliver secure updates to Guix users, and how The Update Framework (TUF)
and related ideas can help us.

To summarize, the problem we’re trying to solve is the “secure” update
of Git checkouts.  That’s because Guix is a set of recipes and code that
is delivered to users/developers using Git.

More specifically, we share most of the security goals listed in
Sections 1.5.2 and 1.5.3 of the TUF spec¹.

TUF is biased towards repositories of binary packages and associated
meta-data, whereas we’re (1) using Git, and (2) concerned with source
code authentication.  Thus, some of the goals in 1.5.2 are not
applicable, as we will see, and some of the roles in 2.1 are not
applicable either.

The OPAM folks came up with a variant of TUF² that takes advantage of
the fact that the OPAM package repository is in a Git repo³ (this design
is not currently used by opam-repository, AFAICS).  Their scheme uses
detached signature files for package meta-data instead of signed
commits; thus, it is not concerned with Git checkout authentication in
general, but with the authentication of individual files in the repo
(see the discussion of “target files” below).  Yet, there are good ideas
applicable to our Git repo, such as the ‘signed’ tag created by a
“signature bot” and that clients can use to check whether they get the
latest version of opam-repository.

The Qubes folks have their own process⁴, not inspired by TUF.  They push
signed Git tags (instead of signing commits), with roughly one signed
tag every time a bunch of commits is pushed⁵.  AIUI, Qubes uses the
OpenPGP web of trust to determine which keys are authorized keys: a key
signed by the Qubes master key is considered authorized.  IMO this is a
misuse of OpenPGP, where a signature on a key is a statement of trust in
(certification of) the key/email and possibly key/name bindings⁶, and
has nothing to do with authorization.

At the very least, it’s clear that:

  1. Guix clients, whether ‘guix pull’ or ‘git pull’, must be able to
     authenticate the history of their checkout; this is why we started
     signing commits.

  2. We must use a mechanism such as the ‘signed’ Git tag described in
     the OPAM document so that clients can know what the latest Guix
     commit is.

  3. We must follow the key management practices developed in TUF.

Let’s go back to the “goals for specific attacks to protect against” in
Section 1.5.2 of the TUF spec, and see how they apply to the
distribution of Guix’s source tree:

  1. “Rollback attacks.  Attackers should not be able to trick clients
     into installing software that is older than that which the client
     previously knew to be available.”

     As explained in the OPAM document, Git gives us linearity
     guarantees (‘git pull’ makes sure we move forward), so clients can
     be sure they move forward in Guix history.  We expect clients to
     authenticate the Git history, making sure all the commits are
     signed by authorized Guix committers.

     To perform such an attack, an attacker would need to get access to
     the private key of one of the authorized committers.  We can
     probably consider it beyond the scope of our threat model, because
     at this point, the attacker could do anything (like the 2nd
     paragraph of TUF Section 2.2 suggests) and the version string of
     packages is really a detail.

  2. “Indefinite freeze attacks.  Attackers should not be able to
     respond to client requests with the same, outdated metadata without
     the client being aware of the problem.”

  3. “Endless data attacks” and “Slow retrieval attacks” seem to be
     beyond the scope of our interests here; TUF does not seem to
     address them either.

  4. “Extraneous dependencies attacks.  Attackers should not be able to
     cause clients to download or install software dependencies that are
     not the intended dependencies.”

     Not applicable: we’re distributing a Git source tree, not build
     artifacts.

  5. “Mix-and-match attacks.  Attackers should not be able to trick clients into
     using a combination of metadata that never existed together on the
     repository at the same time.”

     Not applicable, for the same reaons.

  6. “Malicious repository mirrors should not be able to prevent updates
     from good mirrors.”

     Clients should check the age of the ‘signed’ tag, and thus detect
     outdated mirrors.

Section 2 of the TUF spec defines the notion of “target files” and
discusses roles and the PKI.

“Target files” are defined as files distributed by the system as
commonly found in “traditional” package repos (e.g., binary packages and
associated meta-data); they are the unit of authenticable data.

In Guix we want to authenticate whole checkouts, so the notion of
“target file” seems to make little sense.  For instance, it wouldn’t
make sense to sign each gnu/packages/*.scm file individually, because
the meaning of these files depends not only on the surrounding files,
but also on the core of Guix, such as the (guix packages) module, which
defines the very notion of “package”.

The PKI and roles described in TUF, with separate responsibilities and
the ability to delegate, make a lot of sense (it’s similar in spirit to
SPKI⁷, but more limited in scope.)  Some of the roles do not seem to be
applicable to secure Git update delivery:

  • the “targets” role is not applicable, at least not to individual
    source files;

  • the “snapshot” role does not seem applicable (a Git commit *is* a
    complete snapshot); the “timestamp” role, though, corresponds to the
    signature bot described in the OPAM document;

  • the optional “mirrors” role doesn’t seem very useful, as
    acknowledged by Section 2.1.5 of the TUF spec.

With that in mind, we now need to see how to map the relevant bits of
TUF to Guix!

Comments welcome!

Ludo’.

¹ https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt
² http://opam.ocaml.org/blog/Signing-the-opam-repository/
³ https://github.com/ocaml/opam-repository
⁴ https://www.qubes-os.org/doc/verifying-signatures/
⁵ See for example all the ‘mm_XXX’ tags at
 <https://github.com/QubesOS/qubes-core-agent-linux/releases>.
⁶ https://tools.ietf.org/html/rfc4880#section-5.2
⁷ http://theworld.com/~cme/spki.txt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]