Re: [tor-bugs] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#22940: prop224: HS revision counter should persist after service reboot
----------------------------+------------------------------------
 Reporter:  asn             |          Owner:
     Type:  defect          |         Status:  new
 Priority:  Medium          |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  #20657          |         Points:  1
 Reviewer:                  |        Sponsor:  SponsorR-can
----------------------------+------------------------------------
Description changed by asn:

Old description:

> We currently have the following logic in the HSDir-side when accepting an
> HS descriptor:
> {{{
>     if (cache_entry->plaintext_data->revision_counter >=
>         desc->plaintext_data->revision_counter) {
>       log_info(LD_REND, "Descriptor revision counter in our cache is "
>                         "greater or equal than the one we received. "
>                         "Rejecting!");
>       goto err;
>     }
> }}}
>
> Unfortunately, while HSes keep track of the revision counter in memory,
> they never save it on disk, so if the service reboots the Hs will lose
> track of the rev counter and publish descriptors with small counters that
> will get rejected by the HSDir.
>
> We have brainstormed the following solutions for this:
> a) Save the latest rev counter in the state file in a form like this:
> `HidServRevCounter <service_pubkey> <rev_counter> <time_period_num>
> b) Set the rev counter to a value like `rounddown(time(NULL))` so that
> the HS always generates correct rev counters even without saving them on
> state.
>
> However, wrt (b), since the quoted check above rejects equal rev counters
> the HS will have trouble uploading descriptors in the same hour. We could
> backport a fix that changes the check to 0.3.0 and then do this idea but
> that's kind of a PITA.
>
> We are currently aiming for (a)

New description:

 We currently have the following logic in the HSDir-side when accepting an
 HS descriptor:
 {{{
     if (cache_entry->plaintext_data->revision_counter >=
         desc->plaintext_data->revision_counter) {
       log_info(LD_REND, "Descriptor revision counter in our cache is "
                         "greater or equal than the one we received. "
                         "Rejecting!");
       goto err;
     }
 }}}

 Unfortunately, while HSes keep track of the revision counter in memory,
 they never save it on disk, so if the service reboots the Hs will lose
 track of the rev counter and publish descriptors with small counters that
 will get rejected by the HSDir.

 We have brainstormed the following solutions for this:
 a) Save the latest rev counter in the state file in a form like this:
 `HidServRevCounter <service_pubkey> <rev_counter> <time_period_num>`
 b) Set the rev counter to a value like `rounddown(time(NULL))` so that the
 HS always generates correct rev counters even without saving them on
 state.

 However, wrt (b), since the quoted check above rejects equal rev counters
 the HS will have trouble uploading descriptors in the same hour. We could
 backport a fix that changes the check to 0.3.0 and then do this idea but
 that's kind of a PITA.

 We are currently aiming for (a)

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22940#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs