diff options
Diffstat (limited to 'doc/spec/proposals/162-consensus-flavors.txt')
| -rw-r--r-- | doc/spec/proposals/162-consensus-flavors.txt | 188 |
1 files changed, 0 insertions, 188 deletions
diff --git a/doc/spec/proposals/162-consensus-flavors.txt b/doc/spec/proposals/162-consensus-flavors.txt deleted file mode 100644 index e3b697afee..0000000000 --- a/doc/spec/proposals/162-consensus-flavors.txt +++ /dev/null @@ -1,188 +0,0 @@ -Filename: 162-consensus-flavors.txt -Title: Publish the consensus in multiple flavors -Author: Nick Mathewson -Created: 14-May-2009 -Target: 0.2.2 -Status: Open - -Overview: - - This proposal describes a way to publish each consensus in - multiple simultaneous formats, or "flavors". This will reduce the - amount of time needed to deploy new consensus-like documents, and - reduce the size of consensus documents in the long term. - -Motivation: - - In the future, we will almost surely want different fields and - data in the network-status document. Examples include: - - Publishing hashes of microdescriptors instead of hashes of - full descriptors (Proposal 158). - - Including different digests of descriptors, instead of the - perhaps-soon-to-be-totally-broken SHA1. - - Note that in both cases, from the client's point of view, this - information _replaces_ older information. If we're using a - SHA256 hash, we don't need to see the SHA1. If clients only want - microdescriptors, they don't (necessarily) need to see hashes of - other things. - - Our past approach to cases like this has been to shovel all of - the data into the consensus document. But this is rather poor - for bandwidth. Adding a single SHA256 hash to a consensus for - each router increases the compressed consensus size by 47%. In - comparison, replacing a single SHA1 hash with a SHA256 hash for - each listed router increases the consensus size by only 18%. - -Design in brief: - - Let the voting process remain as it is, until a consensus is - generated. With future versions of the voting algorithm, instead - of just a single consensus being generated, multiple consensus - "flavors" are produced. - - Consensuses (all of them) include a list of which flavors are - being generated. Caches fetch and serve all flavors of consensus - that are listed, regardless of whether they can parse or validate - them, and serve them to clients. Thus, once this design is in - place, we won't need to deploy more cache changes in order to get - new flavors of consensus to be cached. - - Clients download only the consensus flavor they want. - -A note on hashes: - - Everything in this document is specified to use SHA256, and to be - upgradeable to use better hashes in the future. - -Spec modifications: - - 1. URLs and changes to the current consensus format. - - Every consensus flavor has a name consisting of a sequence of one - or more alphanumeric characters and dashes. For compatibility - current descriptor flavor is called "ns". - - The supported consensus flavors are defined as part of the - authorities' consensus method. - - For each supported flavor, every authority calculates another - consensus document of as-yet-unspecified format, and exchanges - detached signatures for these documents as in the current consensus - design. - - In addition to the consensus currently served at - /tor/status-vote/(current|next)/consensus.z and - /tor/status-vote/(current|next)/consensus/<FP1>+<FP2>+<FP3>+....z , - authorities serve another consensus of each flavor "F" from the - locations /tor/status-vote/(current|next)/consensus-F.z. and - /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. - - When caches serve these documents, they do so from the same - locations. - - 2. Document format: generic consensus. - - The format of a flavored consensus is as-yet-unspecified, except - that the first line is: - "network-status-version" SP version SP flavor NL - - where version is 3 or higher, and the flavor is a string - consisting of alphanumeric characters and dashes, matching the - corresponding flavor listed in the unflavored consensus. - - 3. Document format: detached signatures. - - We amend the detached signature format to include more than one - consensus-digest line, and more than one set of signatures. - - After the consensus-digest line, we allow more lines of the form: - "additional-digest" SP flavor SP algname SP digest NL - - Before the directory-signature lines, we allow more entries of the form: - "additional-signature" SP flavor SP algname SP identity SP - signing-key-digest NL signature. - - [We do not use "consensus-digest" or "directory-signature" for flavored - consensuses, since this could confuse older Tors.] - - The consensus-signatures URL should contain the signatures - for _all_ flavors of consensus. - - 4. The consensus index: - - Authorities additionally generate and serve a consensus-index - document. Its format is: - - Header ValidAfter ValidUntil Documents Signatures - - Header = "consensus-index" SP version NL - ValidAfter = as in a consensus - ValidUntil = as in a consensus - Documents = Document* - Document = "document" SP flavor SP SignedLength - 1*(SP AlgorithmName "=" Digest) NL - Signatures = Signature* - Signature = "directory-signature" SP algname SP identity - SP signing-key-digest NL signature - - There must be one Document line for each generated consensus flavor. - Each Document line describes the length of the signed portion of - a consensus (the signatures themselves are not included), along - with one or more digests of that signed portion. Digests are - given in hex. The algorithm "sha256" MUST be included; others - are allowed. - - The algname part of a signature describes what algorithm was - used to hash the identity and signing keys, and to compute the - signature. The algorithm "sha256" MUST be recognized; - signatures with unrecognized algorithms MUST be ignored. - (See below). - - The consensus index is made available at - /tor/status-vote/(current|next)/consensus-index.z. - - Caches should fetch this document so they can check the - correctness of the different consensus documents they fetch. - They do not need to check anything about an unrecognized - consensus document beyond its digest and length. - - 4.1. The "sha256" signature format. - - The 'SHA256' signature format for directory objects is defined as - the RSA signature of the OAEP+-padded SHA256 digest of the item to - be signed. When checking signatures, the signature MUST be treated - as valid if the signature material begins with SHA256(document); - this allows us to add other data later. - -Considerations: - - - We should not create a new flavor of consensus when adding a - field instead wouldn't be too onerous. - - - We should not proliferate flavors lightly: clients will be - distinguishable based on which flavor they download. - -Migration: - - - Stage one: authorities begin generating and serving - consensus-index files. - - - Stage two: Caches begin downloading consensus-index files, - validating them, and using them to decide what flavors of - consensus documents to cache. They download all listed - documents, and compare them to the digests given in the - consensus. - - - Stage three: Once we want to make a significant change to the - consensus format, we deploy another flavor of consensus at the - authorities. This will immediately start getting cached by the - caches, and clients can start fetching the new flavor without - waiting a version or two for enough caches to begin supporting - it. - -Acknowledgements: - - Aspects of this design and its applications to hash migration were - heavily influenced by IRC conversations with Marian. - |