On 21 Jun (11:40:39), teor wrote:

Hi,

Hello teor! Sorry for the delay!

The time period overlap section 2.2.4 in prop224 is under-specified: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...

1. During the overlap period, does the service use the new blinded key for the new period, and the old blinded key for the old period?

I think the answer is yes, but this requires some deduction to work out.

The service will use _both_ blinded keys thus the "current" one and the "next" one. This overlap period makes the service create two descriptors with two different set of keys and intro points.

2. If the overlap period starts when a service sees the first consensus with a new SRV, does the service stop using that SRV and blinded key:

The way the SRV value is used with hidden service is as follow. Once a consensus arrives at the tor client, "routerstatus_t" object are created for each "node_t". It is at that point that we pre-compute the HSDir index using the SRV values in the consensus. Every node_t object has a "hsdir_index" object containing the value of the position on the hashring for the current *and* next period. We do that in order to avoid lots of computation everytime the service wants to upload descriptors. So, if a consensus comes in with *no* SRV, every hsdir_index is set to the position using the disaster value (deterministic). And the service will start uploading there. This can have a bad effect on reachability for client with different consensus *but* HSDir keeps the descriptor for a "descriptor lifetime" which is 3 hours right now by default so there is a window where client will use the SRV from a older consensus and still be able to reach the service. All in all, no SRV in the consensus is pretty bad for reachability. We could try to be more resilient service side with also uploading descriptors to previous SRV hsdir index but I'm relunctant to do that (at least needs more thought) since I would prefer the service to *trust* and *follow* the latest consensus instead of using any old or expired consensus values.

* at the end of the period? (that is, exactly 36 hours after the earliest the overlap period could possibly have started.) * exactly 36 hours after the SRV was first seen? (that is, exactly 36 hours after the service started the overlap period. For example, if the service fetched the consensus 2 hours after it was created, it would end 2 hours after the end of the period.) * when the first reveal consensus is received with that SRV as the previous SRV? (or some similar consensus-driven event)

Does every service on a tor instance start the overlap at the same time?

Yes. Overlap period is between 00:00 and 12:00 UTC. This is the if condition being used: if (valid_after_tm.tm_hour > 0 && valid_after_tm.tm_hour < 12) { ... I just realized though that there is a side effect here. Entering the overlap period means that our next descriptor becomes our current descriptor and then we create a new next descriptor because we are in overlap. Which has this collateral damage of having _all_ hidden service at once closing the intro points of the current descriptor which is being discarded after 36 hours of operation. Not entirely sure that is a good idea to do such a thing at 00:00 every day :P... Keeping that in mind. I hope this answers your question! Cheers! David

https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...

T -- Tim Wilson-Brown (teor)

teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- /mmuJnfgl5BpUcW2QnKLPvo7NTw8BgfpNjOtJ9EM/2U=

teor <teor2345@gmail.com> writes:

Hi,

The time period overlap section 2.2.4 in prop224 is under-specified: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...

1. During the overlap period, does the service use the new blinded key for the new period, and the old blinded key for the old period?

I think the answer is yes, but this requires some deduction to work out.

2. If the overlap period starts when a service sees the first consensus with a new SRV, does the service stop using that SRV and blinded key: * at the end of the period? (that is, exactly 36 hours after the earliest the overlap period could possibly have started.) * exactly 36 hours after the SRV was first seen? (that is, exactly 36 hours after the service started the overlap period. For example, if the service fetched the consensus 2 hours after it was created, it would end 2 hours after the end of the period.) * when the first reveal consensus is received with that SRV as the previous SRV? (or some similar consensus-driven event)

Does every service on a tor instance start the overlap at the same time?

Hey teor, thanks for the good questions! Your questions made us rethink the overlap logic, and check the code to see whether it conforms with the spec. Apparently the code logic is quite different from the spec. I opened two tickets to track progress in this area: #22736: Update spec wrt overlap behavior of HSes #22735: HS desc overlap period func uses absolute times instead of slots