[tor-bugs] #7126 [Tor]: Multipath consensus integrity verification

[Tor Bug Tracker & Wiki]

#7126: Multipath consensus integrity verification
---------------------------------------+------------------------------------
 Reporter:  mikeperry                  |          Owner:                  
     Type:  enhancement                |         Status:  new             
 Priority:  normal                     |      Milestone:  Tor: unspecified
Component:  Tor                        |        Version:                  
 Keywords:  SponsorZ, proposal-needed  |         Parent:                  
   Points:                             |   Actualpoints:                  
---------------------------------------+------------------------------------
 We want to allow clients to use old consensuses safely without the
 directory authorities producing new ones. One of the problems with this is
 ensuring that directory mirrors don't game this time period to feed
 clients their favorite stale consensus that is still acceptable.

 A related problem is "Can we do anything to mitigate malicious targeted
 consensus delivery in the event that a majority of dirauth signing keys
 are compromised?"

 The common approach for this type of problem is multipath Perspectives-
 style key authentication. There are several ways we could authenticate the
 consensus documents in this model. For example, an append-only data
 structure such as a signed git repo could be created to store consensus
 hashes for all time. Tor clients could also be modified to store their own
 chain of observed consensus hashes in a file. In this way, potentially
 targeted users could drop their consensus hash history onto a USB key,
 mail it, relocate or otherwise bootstrap an alternate path to the git
 repo, and verify their connection was not compromised.

 A more streamlined Tor-based solution is to extend current Tor directory
 protocols to allow the set of directory mirrors from #572 to be queried
 about the latest consensus time they have seen, and for the hash for that
 consensus time. Clients could then query k of these mirrors, determine the
 most recent consensus hash that all k mirrors agree on, and request that
 consensus document from the mirrors that have it. Such requests would be
 authenticated by the dir mirror identity keys, which would be stored in
 the Tor source code as part of #572.

 This would require additional directory commands ("Tell me the timestamp
 on your most recent consensus" and "Tell me the hash of that consensus"),
 as well as some client logic.

 The client logic is likely to be the complicated part. It's possible that
 the dirport commands could be added earlier, allowing us to experiment
 with various client approaches on the longer term.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7126>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online