mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-20 10:12:15 +01:00
95 lines
3.5 KiB
Plaintext
95 lines
3.5 KiB
Plaintext
Filename: 139-conditional-consensus-download.txt
|
|
Title: Download consensus documents only when it will be trusted
|
|
Author: Peter Palfrader
|
|
Created: 2008-04-13
|
|
Status: Closed
|
|
Implemented-In: 0.2.1.x
|
|
|
|
Overview:
|
|
|
|
Servers only provide consensus documents to clients when it is known that
|
|
the client will trust it.
|
|
|
|
Motivation:
|
|
|
|
When clients[1] want a new network status consensus they request it
|
|
from a Tor server using the URL path /tor/status-vote/current/consensus.
|
|
Then after downloading the client checks if this consensus can be
|
|
trusted. Whether the client trusts the consensus depends on the
|
|
authorities that the client trusts and how many of those
|
|
authorities signed the consensus document.
|
|
|
|
If the client cannot trust the consensus document it is disregarded
|
|
and a new download is tried at a later time. Several hundred
|
|
kilobytes of server bandwidth were wasted by this single client's
|
|
request.
|
|
|
|
With hundreds of thousands of clients this will have undesirable
|
|
consequences when the list of authorities has changed so much that a
|
|
large number of established clients no longer can trust any consensus
|
|
document formed.
|
|
|
|
Objective:
|
|
|
|
The objective of this proposal is to make clients not download
|
|
consensuses they will not trust.
|
|
|
|
Proposal:
|
|
|
|
The list of authorities that are trusted by a client are encoded in
|
|
the URL they send to the directory server when requesting a consensus
|
|
document.
|
|
|
|
The directory server then only sends back the consensus when more than
|
|
half of the authorities listed in the request have signed the
|
|
consensus. If it is known that the consensus will not be trusted
|
|
a 404 error code is sent back to the client.
|
|
|
|
This proposal does not require directory caches to keep more than one
|
|
consensus document. This proposal also does not require authorities
|
|
to verify the signature on the consensus document of authorities they
|
|
do not recognize.
|
|
|
|
The new URL scheme to download a consensus is
|
|
/tor/status-vote/current/consensus/<F> where F is a list of
|
|
fingerprints, sorted in ascending order, and concatenated using a +
|
|
sign.
|
|
|
|
Fingerprints are uppercase hexadecimal encodings of the authority
|
|
identity key's digest. Servers should also accept requests that
|
|
use lower case or mixed case hexadecimal encodings.
|
|
|
|
A .z URL for compressed versions of the consensus will be provided
|
|
similarly to existing resources and is the URL that usually should
|
|
be used by clients.
|
|
|
|
Migration:
|
|
|
|
The old location of the consensus should continue to work
|
|
indefinitely. Not only is it used by old clients, but it is a useful
|
|
resource for automated tools that do not particularly care which
|
|
authorities have signed the consensus.
|
|
|
|
Authorities that are known to the client a priori by being shipped
|
|
with the Tor code are assumed to handle this format.
|
|
|
|
When downloading a consensus document from caches that do not support this
|
|
new format they fall back to the old download location.
|
|
|
|
Caches support the new format starting with Tor version 0.2.1.1-alpha.
|
|
|
|
Anonymity Implications:
|
|
|
|
By supplying the list of authorities a client trusts to the directory
|
|
server we leak information (like likely version of Tor client) to the
|
|
directory server. In the current system we also leak that we are
|
|
very old - by re-downloading the consensus over and over again, but
|
|
only when we are so old that we no longer can trust the consensus.
|
|
|
|
|
|
|
|
Footnotes:
|
|
1. For the purpose of this proposal a client can be any Tor instance
|
|
that downloads a consensus document. This includes relays,
|
|
directory caches as well as end users.
|