[tor-dev] Proposal: Don't include package fingerprints in consensus documents

[Iain Learmonth]

Hi All,

#28465 [0] needed a proposal. Feedback is welcome and encouraged. I've
not written a proposal before, so if someone could let me know if I'm
following the process OK (or not) then that is useful too.

Thanks,
Iain.

[0] https://trac.torproject.org/projects/tor/ticket/28465

-------------- next part --------------
Filename: xxx-dont-vote-on-package-fingerprints.txt
Title: Don't include package fingerprints in consensus documents
Author: Iain R. Learmonth
Created: 2019-02-21
Status: Open
Ticket: #28465

0. Abstract

   I propose modifying the Tor consensus document to remove
   digests of the latest versions of one or more package files, to
   prevent software using Tor from determining its up-to-dateness, and
   to hinder users wanting to verify that they are getting the correct
   software.

1. Introduction

   In proposal 227 [1], to improve the integrity and security of
   updates, a way to authenticate the latest versions of core Tor
   software through the consensus was described. By listing a location
   with this information for each version of each package, we can
   augment the update process of Tor software to authenticate the
   packages it downloads through the Tor consensus. This was
   implemented in tor 0.2.6.3-alpha.

   When looking at modernising our network archive recently [2], I
   came across this line for votes and consensuses. If packages are
   referenced by the consensus then ideally we should archive those
   packages just as we archive referenced descriptors. However, this
   line was never present in any vote archived.

2. Proposal

   We deprecate the "package" line in the specification for votes.

   If the consensus method is at least XX then "package" lines should
   not appear in consensuses.

3. Security Considerations

   This proposal removes a feature that could be used for improved
   security but currently isn't. As such it is extra code in the
   codebase that may have unknown bugs or lead to bugs in the future
   due to unexpected interactions. Overall this should be a good
   thing for security of Core Tor.

4. Compatability Considerations

   A new consensus method is required for this proposal. The
   "package" line was always optional and so no client should be
   depending on it. There are no known consumers of the "package"
   lines (there are none to consume anyway).

A. References

   [1] Nick Mathewson, Mike Perry. "Include package fingerprints in
       consensus documents". Tor Proposal 227, February 2014.
   [2] Iain Learmonth, Karsten Loesing. "Towards modernising data
       collection and archive for the Tor network". Technical Report
       2018-12-001, December 2018.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190221/a428d545/attachment.sig>