139-conditional-consensus-download.txt 3.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293
  1. Filename: 139-conditional-consensus-download.txt
  2. Title: Download consensus documents only when it will be trusted
  3. Author: Peter Palfrader
  4. Created: 2008-04-13
  5. Status: Closed
  6. Overview:
  7. Servers only provide consensus documents to clients when it is known that
  8. the client will trust it.
  9. Motivation:
  10. When clients[1] want a new network status consensus they request it
  11. from a Tor server using the URL path /tor/status-vote/current/consensus.
  12. Then after downloading the client checks if this consensus can be
  13. trusted. Whether the client trusts the consensus depends on the
  14. authorities that the client trusts and how many of those
  15. authorities signed the consensus document.
  16. If the client cannot trust the consensus document it is disregarded
  17. and a new download is tried at a later time. Several hundred
  18. kilobytes of server bandwidth were wasted by this single client's
  19. request.
  20. With hundreds of thousands of clients this will have undesirable
  21. consequences when the list of authorities has changed so much that a
  22. large number of established clients no longer can trust any consensus
  23. document formed.
  24. Objective:
  25. The objective of this proposal is to make clients not download
  26. consensuses they will not trust.
  27. Proposal:
  28. The list of authorities that are trusted by a client are encoded in
  29. the URL they send to the directory server when requesting a consensus
  30. document.
  31. The directory server then only sends back the consensus when more than
  32. half of the authorities listed in the request have signed the
  33. consensus. If it is known that the consensus will not be trusted
  34. a 404 error code is sent back to the client.
  35. This proposal does not require directory caches to keep more than one
  36. consensus document. This proposal also does not require authorities
  37. to verify the signature on the consensus document of authorities they
  38. do not recognize.
  39. The new URL scheme to download a consensus is
  40. /tor/status-vote/current/consensus/<F> where F is a list of
  41. fingerprints, sorted in ascending order, and concatenated using a +
  42. sign.
  43. Fingerprints are uppercase hexadecimal encodings of the authority
  44. identity key's digest. Servers should also accept requests that
  45. use lower case or mixed case hexadecimal encodings.
  46. A .z URL for compressed versions of the consensus will be provided
  47. similarly to existing resources and is the URL that usually should
  48. be used by clients.
  49. Migration:
  50. The old location of the consensus should continue to work
  51. indefinitely. Not only is it used by old clients, but it is a useful
  52. resource for automated tools that do not particularly care which
  53. authorities have signed the consensus.
  54. Authorities that are known to the client a priori by being shipped
  55. with the Tor code are assumed to handle this format.
  56. When downloading a consensus document from caches that do not support this
  57. new format they fall back to the old download location.
  58. Caches support the new format starting with Tor version 0.2.1.1-alpha.
  59. Anonymity Implications:
  60. By supplying the list of authorities a client trusts to the directory
  61. server we leak information (like likely version of Tor client) to the
  62. directory server. In the current system we also leak that we are
  63. very old - by re-downloading the consensus over and over again, but
  64. only when we are so old that we no longer can trust the consensus.
  65. Footnotes:
  66. 1. For the purpose of this proposal a client can be any Tor instance
  67. that downloads a consensus document. This includes relays,
  68. directory caches as well as end users.