aboutsummaryrefslogtreecommitdiff
path: root/proposals/289-authenticated-sendmes.txt
diff options
context:
space:
mode:
authorDavid Goulet <dgoulet@torproject.org>2019-05-21 11:27:51 -0400
committerDavid Goulet <dgoulet@torproject.org>2019-05-21 11:27:51 -0400
commit33cc0fef51e584056543bc2059ca9b53b9493afb (patch)
tree0fb34133e6fc59555f6d90addda4616ab7f4bf4f /proposals/289-authenticated-sendmes.txt
parent9503a261020ad906bb07595d8fba25b4542bba8a (diff)
downloadtorspec-33cc0fef51e584056543bc2059ca9b53b9493afb.tar.gz
torspec-33cc0fef51e584056543bc2059ca9b53b9493afb.zip
prop289: Simplify and clarify deployment plan
Signed-off-by: David Goulet <dgoulet@torproject.org>
Diffstat (limited to 'proposals/289-authenticated-sendmes.txt')
-rw-r--r--proposals/289-authenticated-sendmes.txt58
1 files changed, 16 insertions, 42 deletions
diff --git a/proposals/289-authenticated-sendmes.txt b/proposals/289-authenticated-sendmes.txt
index c712a8d..c9eada6 100644
--- a/proposals/289-authenticated-sendmes.txt
+++ b/proposals/289-authenticated-sendmes.txt
@@ -309,7 +309,7 @@ Status: Open
protected from attack. It's not all bad news though, since we could flip
the switches earlier than intended if we encounter a network-wide attack.
- There are 5 phases to this plan and detailed in the subsections.
+ There are 4 phases to this plan detailed in the following subsections.
4.1. Phase One - Remembering Digests
@@ -360,49 +360,28 @@ Status: Open
"sendme_accept_min_version" - Minimum SENDME version that is accepted.
- (It has to be two separate switches, not one unified one, because
- otherwise we'd have a race where relays learn about the update before
- clients know to start the new behavior.)
+ It has to be two separate switches, not one unified one, because otherwise
+ we'd have a race where relays learn about the update before clients know to
+ start the new behavior.
- Phase three will shutdown every clients that understand protover. However,
- one important case remains which is when a client not supporting verison 1
- boots up for the first time (no consensus).
+4.5. Timeline
- It won't be able to download a consensus and thus know that it can't join
- the network making it re-try over and over again. To avoid that, we propose
- to still allow v0 SENDMEs on one-hop directory circuits meaning the new
- parameter above affects everything except these specific circuits.
-
- It will allow us to extend the period of time between Phase Four and too
- old clients to bootstrap and fail properly. The last phase will then turn
- this behavior off and we will be done once and for all with version 0.
-
-4.5. Phase Five - Turning Off v0
-
- The last consensus switch to flip is the one refusing SENDME v0 on one-hop
- directory circuit as described in previous phase.
-
- The newly proposed consensus parameter to achieve this is:
-
- "sendme_onehop_dir_min_version" - Minimum SENDME version that is
- accepted on one-hop directory circuits.
-
- After this phase, any tor still not supporting v0 will retry over and over
- again to bootstrap. We can't avoid that but at least we can give enough
- time to minimize the amount of old clients unable to boostrap with the
- proposed timeline below.
+ The proposed timeline for the deployment phases:
-4.6. Timeline
+ Phase 1:
- The proposed timeline for the deployment phases:
+ Once this proposal is merged into tor (expected: 0.4.1.1-alpha), v1
+ SENDMEs can be accepted on a circuit.
- Phase 1 and 2:
+ Phase 2:
- Once this proposal is merged into tor (expected: 0.4.1.1-alpha).
+ Once Tor Browser releases a stable version containing 0.4.1, we
+ consider that we have a very large portion of clients supporting v1
+ and thus limit the partition problem.
- Those two phases will start roughly at the same time. The reason we
- can do that is because SENDME payloads are ignored for version 0 thus
- sending v1 right now will not affect Tor current behavior.
+ We can safely emit v1 SENDMEs in the network because the payload is
+ ignored for version 0 thus sending a v1 right now will not affect
+ older tor's behavior and will be considered a v0.
Phase 3:
@@ -420,11 +399,6 @@ Status: Open
Considering 6 months release time frame we expect to do this phase
around July 2022.
- Phase 5:
-
- Depends on how Phase 4 goes. It could be we'll do that very quickly
- or not depending on our users and also Tor situation/health in 2022.
-
5. Security Discussion
Does our design enable any new adversarial capabilities?