New proposal 342: Decoupling hs_interval and SRV lifetime

4 files changed, 111 insertions, 0 deletions

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