[tor-dev] Proposal 342: Decouple hs_interval and SRV lifetime

[David Goulet]

On 23 Jan (13:31:49), Nick Mathewson wrote:
> On Tue, Jan 10, 2023 at 8:22 AM Nick Mathewson <nickm at torproject.org> wrote:
> 
> > ```
> > 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
> >
> >
> I think there's another issue to address here too: the offset from the Unix
> Epoch at which the first Time Period begins.  According to rend-spec-v3,
> 
> "we want our time periods to start at 12:00UTC every day, so
> we subtract a "rotation time offset" of 12*60 minutes from the number of
> minutes since the epoch, before dividing by the time period (effectively
> making "our" epoch start at Jan 1, 1970 12:00UTC)."
> 
> But this isn't exactly what the C Tor implementation does.  In
> `hs_get_time_period_num(),` it defines the offset as
> `sr_state_get_phase_duration()`, which is tied to the voting interval and
> the constant SHARED_RANDOM_N_ROUNDS (which is 12).
> 
> David, do you have any thoughts on the right solution here?  Some options
> are:
>   * We could document the current behavior.
>   * We could add a consensus parameter for the time period offset.
>   * We could define the time period offset as exactly 12 hours in all
> cases. (I guess this would break test networks though?)
>   * Something else?

My intuition here would be to document current behavior. This shared random
ritual is tied to the voting protocol (interval) because it has these commit +
reveal phases thus using the voting interval between phase rounds is
foundational.

And so, I would keep those two tied and simply document.

What we can think of is to add consensus parameters for how many rounds per
phase instead of these hardcoded values in our C-tor code but unclear to me
what it would give us in the long run. But for the interval, I would keep the
voting one. We get TestingNetwork for free also with this.

Whatever we do, the very important piece here is that we can't end up with a
protocol taking more time than our MinUptimeHidServDirectoryV2 value (minimum
uptime for a relay before becoming an HSDir).

And so let say one day we change the voting interval to every 4 hours then we
end up with 24 rounds of voting to complete the commit + reveal phases meaning
a total of 96 hours (which is current value of MinUptimeHidServDirectoryV2)
thus borderline no good.

(Maybe something to keep in mind for arti-relay authorities to check on...).

Hope this help with your question?

Cheers!
David

-- 
pG2H247H2MnipNmet9NVk2ZChKK1OeFLQ50ZwK2ROe4=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230124/81596899/attachment.sig>