RFC/proposal for Thandy changes

[Justin Samuel]

Hi all,

Here's my first pass at proposed Thandy changes as discussed on irc a couple
of weeks ago.

Justin

0. Proposed Thandy Changes
==========================

This is a set of proposals that includes a section of simple changes that can
be considered on their own (Section 1) as well as a more fundamental Thandy
restructuring proposal (Section 2).

This isn't meant to be at the level of detail needed for a spec and subsequent
implementation. This is to get feedback and promote discussion. It's not an
official proposal at this point but more of a request for comment.

A few relevant documents for reference:

 * Thandy spec:
   https://gitweb.torproject.org/thandy.git/blob_plain/HEAD:/specs/thandy-spec.txt
 * TUF spec: https://www.updateframework.com/browser/specs/tuf-spec.txt
 * High-level differences between Thandy and TUF:
   https://www.updateframework.com/wiki/ThandyDifferences
 * Paper on TUF: http://www.freehaven.net/~arma/tuf-ccs2010.pdf

1. Individual Thandy Changes
============================

These are changes that could be made to Thandy without major overhaul and can
be considered separately of the restructuring proposal (Section 2).

1.1. Multiple File Hashes
-------------------------

Make all file hashes be a set of (algorithm, digest) pairs rather than a
single digest of a predefined algorithm. Thus, instead of describing a file's
hash in metadata with:

  "hash" : 349dceb3de2db82e363c3d73063f031c56c5aac5

It would be described as:

  "hash" : ["sha1" : 349dceb3de2db82e363c3d73063f031c56c5aac5,
            "sha256" : 95eaa1682a99fba24b26c94499b545...747d7759ba845c8b5c]

Note that it could still be allowed to list only one digest. This just allows
the ability to use multiple hashes. It's up to the client implementation to
determine which are checked.

1.2. Refer to Keys by Their ID when Delegating
----------------------------------------------

In the Thandy key list file (the "root metadata"), the full keys are listed
each time they are referenced. This may decrease the human readability of the
key list.

An alternative approach is to use a separate section in the file that defines
the keys that will be used in the rest of this metadata file, list them with
their ID (a hash of the canonical format of the key), and then refer to them
later by this ID. This is similar to how signatures are already done in
Thandy: the ID of the key is listed along with the signature.

An implementation of this needs to check for ID collisions when reading keys
from metadata. It's fine to see the same key specified with the same ID, but a
different key with the same ID as one that has been seen indicates something
wrong. (Note that the implementation would always check that the specified IDs
are correct for the corresponding key, even without collisions.)

1.3. Indicate Signature Thresholds
----------------------------------

The current Thandy spec isn't clear about how multiple keys are specified for
a role. There also doesn't appear to be a way to specify a threshold that is
less than the total number of keys. The method of specifying multiple keys
should be made clear and the ability to indicate the number of signatures of
those keys that are required should be added. (There's an example of how this
can be specified in metadata in Section 2.2.)

1.4. Add a 'Release' Role
-------------------------

Thandy currently lists the hashes of all other metadata in the timestamp file.
There are certain attacks that could be mitigated if the Timestamp role signed
a separate Release role's metadata that listed the hashes of all other
metadata files. The idea here is that an attacker who compromises only the
Timestamp role cannot present clients with a mix-and-match of signed metadata
files that were available from the repository at different times. The
separation helps because the Timestamp role has a higher likelihood of key
compromise because the keys are used in an automated fashion, whereas the
Release role would not be used in an automated fashion.

Though the idea of a metadata mix-and-match attack is in general something
worth keeping in mind, it may be the case that Thandy isn't at much risk
because bundles serve a similar role of grouping together package versions in
a way that attackers can't cause the clients to use an unintended combination
of package versions. The risk to Thandy depends on whether packagers ever
replace a package version rather than increment it (they aren't supposed to
ever replace a version) and whether Thandy bundles always specify exact
package versions rather than minimum/maximum package versions or package
version ranges.

2. Thandy Restructuring Proposal
================================

Primary goal: Keep Thandy's concepts of bundles and packages but overlay them
on top of the generic 'targets' approach of TUF.

Note: This proposal is not advocating using/maintaining/relying on TUF as a
separate project. That depends on factors such as the future of TUF according
to the current TUF maintainers, whether Python is an appropriate choice for
Windows clients, etc.

2.1 Approach
------------

Two separate layers:

  1. An authentication layer that downloads and authenticates opaque 'target'
     files according to metadata it understands that lists hashes and sizes of
     the target files. This layer doesn't understand what bundles and packages
     are.

  2. A decision/installation layer that uses the authentication layer to
     download bundle/package info and associated files. This layer doesn't
     know the details of the authentication mechanisms or roles; it gets
     files from the authentication layer that the authentication layer has
     already authenticated.

     * Note that the update decision and installation code are probably
       separate, but for the sake of this proposal all that matters is that
       the Thandy authentication layer is logically separate from the rest of
       Thandy.

For the authentication layer, we start with the following roles (the same as
TUF uses):

  * Root
    o Root of trust for the entire PKI. Indicates through signed
      metadata which keys are trusted for the Release, Targets, Timestamp, and
      Mirror roles.

  * Timestamp
    o Signs a frequently regenerated timestamp file with a short
      expiration indicating the most recent release metadata.

  * Release
    o Signs the release metadata which lists the hashes and sizes of all
      other metadata files (other than the timestamp file). Note that
      bundleinfo and pkginfo are not considered metadata at the authentication
      layer.

  * Targets
    o Signs a metadata file that lists the hashes and sizes of target
      files: the files that the decision layer ultimately wants to obtain.
    o Can delegate to sub-roles the responsibility for providing target
      files from specific paths on the repository (e.g. Role A is trusted to
      provide files from the /targets/role_a/ directory).

  * Mirror
    o Signs a metadata file that lists the locations and details of
      repository mirrors.