Opened 6 years ago

Last modified 19 months ago

#7126 new enhancement

Multipath consensus integrity verification

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: SponsorZ, key-theft, proposal-needed, tor-dirauth, term-project
Cc: ln5, cass Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

TicketTypeStatusOwnerSummary
#7282enhancementnewCreate consensus-info directory commands

Change History (10)

comment:1 Changed 6 years ago by mikeperry

Actually, there's probably no reason not to do the git repo, the dir mirror thing, and any number of other additional auxiliary approaches. We might want to consider creating some child tickets for these separate approaches.

comment:2 Changed 6 years ago by nickm

Keywords: tor-auth added

comment:3 Changed 5 years ago by mikeperry

Leif pointed out that another way to do this is to use the slack space in the bitcoin blockchain to publish these consensus history hashes, which would automatically provide an append-only data structure with verifiable, signed statements that cannot be retracted later.

comment:4 Changed 5 years ago by mikeperry

Keywords: key-theft added

comment:5 Changed 5 years ago by mikeperry

A Certificate Transparency-style audit log of consensus document hashes is also a possibility here. However, Certificate Transparency is not geared towards storing plain hashes atm, so we would have to modify the code and the protocol. http://www.certificate-transparency.org/

comment:6 Changed 5 years ago by ln5

Cc: ln5 added

comment:7 Changed 2 years ago by cass

Cc: cass added
Severity: Normal

This ticket is tagged SponsorZ, but it looks like progress stalled three years ago. Is this still an active issue that needs funding?

Last edited 2 years ago by cass (previous) (diff)

comment:8 Changed 2 years ago by nickm

There are different proposals in this general area, like the CT-like work listed above. This particular item is not necessarily how we'd do it, but it could improve the resilience of our consensus system to do *something* like this.

comment:9 Changed 19 months ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:10 Changed 19 months ago by nickm

Keywords: term-project added
Note: See TracTickets for help on using tickets.