commit 68177157137e97359511cdf86675af2df3a3628c Author: Nick Mathewson <nickm@torproject.org> Date: Fri Aug 26 13:48:26 2016 -0400 Add a proposal for a better way to do 266 --- proposals/000-index.txt | 2 + proposals/272-valid-and-running-by-default.txt | 59 ++++++++++++++++++++++++++ 2 files changed, 61 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 41aec3d..d0376cd 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -192,6 +192,7 @@ Proposals by number: 269 Transitionally secure hybrid handshakes [DRAFT] 270 RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope [DRAFT] 271 Another algorithm for guard selection [OPEN] +272 Listed routers should be Valid, Running, and treated as such [OPEN] Proposals by status: @@ -251,6 +252,7 @@ Proposals by status: 262 Re-keying live circuits with new cryptographic material 264 Putting version numbers on the Tor subprotocols 271 Another algorithm for guard selection + 272 Listed routers should be Valid, Running, and treated as such ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/272-valid-and-running-by-default.txt b/proposals/272-valid-and-running-by-default.txt new file mode 100644 index 0000000..7e14b6b --- /dev/null +++ b/proposals/272-valid-and-running-by-default.txt @@ -0,0 +1,59 @@ +Filename: 272-valid-and-running-by-default.txt +Title: Listed routers should be Valid, Running, and treated as such +Created: 26 Aug 2016 +Author: Nick Mathewson +Status: Open + +1. Introduction and proposal. + + This proposal describes a change in how clients understand consensus + flags, and how authorities vote on consensuses. + +1.1. Authority-side changes + + Back in proposal 138, we made it so that non-Running routers were not + included in the consensus documents. We should do the same with the + Valid flag. Specifically, after voting, if the authorities find that + a router would not receive the Valid flag, they should not include it + at all. + + This will require the allocation of a new consensus method, since it + is a change in how consensuses are made from votes. + + In the most recent consensus, it will affect exactly 1 router. + +1.2. Client-side changes + + I propose that clients should consider every listed router to be + listed as Running and Valid if any consensus method above or higher + is in use. + +2. Benefits + + Removing the notion of listed but invalid routers will remove an + opportunity for error, and let us remove some client side code. + + More interestingly, the above changes would allow us to eventually + stop including the Running and Valid flags, thereby providing an + authority-side way to feature-gate clients off of the Tor network + without a fast-zombie problem. (See proposal 266 for discussion.) + + +A. An additional possible change + + Perhaps authorities might also treat BadExit like they treat the + absence of Valid and Running: as sufficient reason to not include a + router in the consensus. Right now, there are only 4 listed BadExit + routers in the consensus, amounting to a small fraction of total + bandwidth. + + Making this change would allow us to remove the client-side badexit + logic. + + +B. Does this solve the zombie problem? + + I tested it a little, and it does seem to be a way to make even the + most ancient consensus-understanding Tors stop fetching descriptors + and using the network. More testing needed though. +