[or-cvs] r9042: Write the remaining bits of dir-voting.txt that I feel smart (in tor/trunk: . doc)
nickm at seul.org
nickm at seul.org
Thu Dec 7 18:57:25 UTC 2006
Date: 2006-12-07 13:57:22 -0500 (Thu, 07 Dec 2006)
New Revision: 9042
r11460 at Kushana: nickm | 2006-12-07 13:05:27 -0500
Write the remaining bits of dir-voting.txt that I feel smart enough to write at the moment. There are still some open questions about timelines and about how to get multilevel keys working.
Property changes on: tor/trunk
svk:merge ticket from /tor/trunk [r11460] on c95137ef-5f19-0410-b913-86e773d04f59
--- tor/trunk/doc/dir-voting.txt 2006-12-07 17:04:44 UTC (rev 9041)
+++ tor/trunk/doc/dir-voting.txt 2006-12-07 18:57:22 UTC (rev 9042)
@@ -89,6 +89,9 @@
authority's nickname, which MUST be unique among authorities, and
MUST match the nickname in the "directory-signature" entry.
+ "directory-signature" -- [XXXX this should be tagged with the nickname
+ or identity somehow.]
Authorities SHOULD cache their most recently generated votes so they
can persist them across restarts. Authorities SHOULD NOT generate
another document until valid-until has passed.
@@ -102,7 +105,6 @@
XXXX some way to request older networkstatus docs?
2.2. Consensus directory specifications
Consensuses are like v2.1 votes, except for the following fields:
@@ -142,22 +144,75 @@
directory-signature, sorted in ascending order by nickname,
- A router entry should be included in the result if it is included by
- more than half of the authorities (total authorities, not just those
- whose votes we have). A router entry has a flag set if it is included
- by more than half of the authorities who care about that flag. [XXXX
- this creates a DOS incentive. Can we remember what flags people set the
- last time we saw them?]
+ A router entry should be included in the result if it is included by more
+ than half of the authorities (total authorities, not just those whose votes
+ we have). A router entry has a flag set if it is included by more than
+ half of the authorities who care about that flag. [XXXX this creates an
+ incentive for attackers to DOS authorities whose votes they don't like.
+ Can we remember what flags people set the last time we saw them?]
- [What does the signature hash cover ? XXX]
+ The signature hash covers from the "network-status-version" line through
+ the characters "directory-signature" in the first "directory-signature"
-2.3. Agreement and timeline
+ Consensus directories SHOULD be rejected if they are not signed by more
+ than half of the known authorities.
- [XXXX publish signed vote summaries.]
- [XXXX URL list: vote, other people's votes, directory.]
- [XXXX in-progress URL vs done URL]
+2.2.1. Detached signatures
+ Assuming full connectivity, every authority should compute and sign the
+ same consensus directory in each period. Therefore, it isn't necessary to
+ download the consensus computed by each authority; instead, the authorities
+ only push/fetch each others' signatures. A "detached signature" document
+ contains a single "consensus-digest" entry and one or more
+ directory-signature entries. [XXXX specify more.]
+2.3. URLs and timelines
+2.3.1. URLs and timeline used for agreement
+ A router SHOULD publish its vote immediately at the start of each voting
+ period. It does this by making it available at
+ and posting it to each other authority at the URL
+ If, N minutes after the voting period has begun, an authority does not have
+ a current statement from another authority, the first authority retrieves
+ the other's statement.
+ Once an authority has a vote from another authority, it makes it available
+ where <fp> is the fingerprint of the other authority's identity key.
+ The consensus network status, along with as many signatures as the server
+ currently knows, should be available at
+ All of the detached signatures it knows for consensus status should be
+ available at:
+ Once an authority has computed and signed a consensus network status, it
+ should send its detached signature to each other authority at the URL
[XXXX Store votes to disk.]
+2.3.2. Serving a consensus directory
+ Once the authority is done getting signatures on the consensus directory,
+ it should serve it from:
+ Caches SHOULD download consensus directories from an authority and serve
+ them from the same URL.
+2.3.3. Timeline and synchronization
2.4. Distributing routerdescs between authorities
Consensus will be more meaningful if authorities take steps to make sure
@@ -273,6 +328,16 @@
- For directory voting, ...
+ For directory voting:
+ * It would be cool if caches could get ready to download these, verify
+ enough signatures, and serve them now. That way once stuff works all
+ we need to do is upgrade the authorities. Caches don't need to verify
+ the correctness of the format so long as it's signed.
-caches need to start caching consensuses and accepting multisigned documents.
+ For dropping the "opt" requirement:
+ * stop requiring it as of 0.1.2.x. Stop generating it once earlier
+ formats are obsolete.
+ For multilevel keys:
+ * no idea
More information about the tor-commits