This is an automated email from the git hooks/post-receive script.
nickm pushed a commit to branch main in repository torspec.
The following commit(s) were added to refs/heads/main by this push: new 578145b New proposal 342: Decoupling hs_interval and SRV lifetime 578145b is described below
commit 578145bf1c64a65a652f58425bf3986a65a0ccb2 Author: Nick Mathewson nickm@torproject.org AuthorDate: Tue Jan 10 08:20:42 2023 -0500
New proposal 342: Decoupling hs_interval and SRV lifetime --- proposals/000-index.txt | 2 + proposals/342-decouple-hs-interval.md | 107 ++++++++++++++++++++++++++++++++++ proposals/BY_INDEX.md | 1 + proposals/README.md | 1 + 4 files changed, 111 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 0f82741..a838b94 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -262,6 +262,7 @@ Proposals by number: 339 UDP traffic over Tor [ACCEPTED] 340 Packed and fragmented relay messages [OPEN] 341 A better algorithm for out-of-sockets eviction [OPEN] +342 Decoupling hs_interval and SRV lifetime [DRAFT]
Proposals by status: @@ -272,6 +273,7 @@ Proposals by status: 327 A First Take at PoW Over Introduction Circuits 329 Overcoming Tor's Bottlenecks with Traffic Splitting 331 Res tokens: Anonymous Credentials for Onion Service DoS Resilience + 342 Decoupling hs_interval and SRV lifetime NEEDS-REVISION: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] diff --git a/proposals/342-decouple-hs-interval.md b/proposals/342-decouple-hs-interval.md new file mode 100644 index 0000000..395c454 --- /dev/null +++ b/proposals/342-decouple-hs-interval.md @@ -0,0 +1,107 @@ +``` +Filename: 342-decouple-hs-interval.md +Title: Decoupling hs_interval and SRV lifetime +Author: Nick Mathewson +Created: 9 January 2023 +Status: Draft +``` + +# Motivation and introduction + +Tor uses shared random values (SRVs) in the consensus to determine +positions of relays within a hash ring. Which shared random value is to +be used for a given time period depends upon the time at which that +shared random value became valid. + +But right now, the consensus voting period is closely tied to the shared +random value voting cycle: and clients need to understand both of these +in order to determine when a shared random value became current. + +This creates tight coupling between: + * The voting schedule + * The SRV liveness schedule + * The hsdir_interval parameter that determines the length of the + an HSDIR index + +To decouple these values, this proposal describes a forward compatible +change to how Tor reports SRVs in consensuses, and how Tor decides which +hash ring to use when. + + +## Reporting SRV timestamps + +In consensus documents, parties should begin to accept +`shared-rand-*-value` lines with an additional argument, in the format +of an IsoTimeNospace timestamp (like "1985-10-26T00:00:00"). When +present, this timestamp indicates the time at which the given shared +random value first became the "current" SRV. + +Additionally, we define a new consensus method that adds these +timestamps to the consensus. + +We specify that, in the absence of such a timestamp, parties are to +assume that the `shared-rand-current-value` SRV became "current" at the +first 00:00 UTC on the UTC day of the consensus's valid-after timestamp, +and that the `shard-rand-previous-value` SRV became "current" at 00:00 +UTC on the previous UTC day. + + +## Generalizing HSDir index scheduling. + +Under the current HSDir design, there is one SRV for each time period, +and one time period for which each SRV is in use. Decoupling +`hsdir_interval` from 24 hours will require that we change this notion +slightly. + +We therefore propose this set of generalized directory behavior rules, +which should be equivalent to the current rules under current +parameters. + +The calculation of time periods remains the same (see `rend-spec-v3.txt` +section `[TIME PERIODS]`). + +A single SRV is associated with each time period: specifically, the SRV +that was "current" at the start of the time period. + +There is a separate hash ring associated with each time period and its +SRV. + +Whenever fetching an onion service descriptor, the client uses the hash +ring for the time period that contains the start of the liveness +interval of the current consensus. Call this the "Consensus" time period. + +Whenever uploading an onion service descriptor, the service uses _two or +three_ hash rings: + * The "consensus" time period (see above). + * The immediately preceding time period, if the SRV to calculate that + hash ring is available in the consensus. + * The immediately following time period, if the SRV to calculate that + hash ring is available in the consensus. + +(Under the current parameters, where `hsdir_interval = SRV_interval`, +there will never be more than two possible time periods for which the +service can qualify.) + +## Migration + +We declare that, for at least the lifetime of the C tor client, we will +not make any changes to the voting interval, the SRV interval, or the +`hsdir_interval`. As such, we do not need to prioritize implementing +these changes in the C client: we can make them in Arti only. + +## Issues left unsolved + +There are likely other lingering issues that would come up if we try to +change the voting interval. This proposal does not attempt to solve +them. + +This proposal does not attempt to add flexibility to the SRV voting +algorithm itself. + +Changing `hsdir_interval` would create a flag day where everybody using +old and new values of `hsdir_interval` would get different hash +rings. We do not try to solve that here. + +## Acknowledgments + +Thanks to David Goulet for explaining all of this stuff to me! diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index b64ae55..d0b1214 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -259,4 +259,5 @@ Below are a list of proposals sorted by their proposal number. See * [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor [ACCEPTED] * [`340-packed-and-fragmented.md`](/proposals/340-packed-and-fragmented.md): Packed and fragmented relay messages [OPEN] * [`341-better-oos.md`](/proposals/341-better-oos.md): A better algorithm for out-of-sockets eviction [OPEN] +* [`342-decouple-hs-interval.md`](/proposals/342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime [DRAFT]
diff --git a/proposals/README.md b/proposals/README.md index 4127329..0461d6a 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -109,6 +109,7 @@ discussion. * [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits * [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting * [`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience +* [`342-decouple-hs-interval.md`](/proposals/342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime
## NEEDS-REVISION proposals: ideas that we can't implement as-is