[tor-dev] prop224: Time Period Overlaps and Blinded Keys

[David Goulet]

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.txt#n821
> 
> 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.txt#n768
> 
> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


-- 
/mmuJnfgl5BpUcW2QnKLPvo7NTw8BgfpNjOtJ9EM/2U=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170623/79b4dbb2/attachment.sig>