Add the long finished conditional-consensus-download proposal as 139

svn:r15288

1 files changed, 93 insertions, 0 deletions

diff --git a/proposals/139-conditional-consensus-download.txt b/proposals/139-conditional-consensus-download.txt
new file mode 100644
index 0000000..6cd8c37
--- /dev/null
+++ b/proposals/139-conditional-consensus-download.txt
@@ -0,0 +1,93 @@
+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
+
+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.