| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394 | 
							- 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.
 
 
  |