commit 33cc0fef51e584056543bc2059ca9b53b9493afb Author: David Goulet <dgoulet@torproject.org> Date: Tue May 21 11:27:51 2019 -0400 prop289: Simplify and clarify deployment plan Signed-off-by: David Goulet <dgoulet@torproject.org> --- proposals/289-authenticated-sendmes.txt | 58 +++++++++------------------------ 1 file 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?