[tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Mar 20 11:22:55 UTC 2018


#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
----------------------------+----------------------------------
 Reporter:  asn             |          Owner:  (none)
     Type:  defect          |         Status:  new
 Priority:  Medium          |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor    |        Version:  Tor: 0.3.1.9
 Severity:  Normal          |     Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:                  |         Points:  4
 Reviewer:                  |        Sponsor:
----------------------------+----------------------------------
Description changed by asn:

Old description:

> Armadev discovered that hsv3 revision counters are harmful to scalability
> since if an onion service is hosted by multiple servers (like the fb
> one), every server should have visibility of the revision counter if they
> want to publish a descriptor.
>
> We should figure out whether there is an easy way around that, or whether
> this is actually a big problem for scalable v3s.
>
> Rev counters are there so that HSDirs (and other actors) cannot replay
> old HS descriptors. However, they are not really needed since now HS
> descriptors are only replayable for a day (before the blinded key gets
> refreshed), and also HSDirs could keep a replay cache of the descriptor
> assigned to a blinded key.
>
> If we decide to rip them off, the way to do it is in two painful steps:
> a) Remove rev counter checking from HSDirs, and do a replay cache or
> something.
> b) In the far future, when all HSDirs have upgraded to (a), rip out the
> rev counter code from onion services.

New description:

 Armadev discovered that hsv3 revision counters are harmful to scalability
 since if an onion service is hosted by multiple servers (like the fb one),
 every server should have visibility of the revision counter if they want
 to publish a descriptor.

 We should figure out whether there is an easy way around that, or whether
 this is actually a big problem for scalable v3s. We should also consider
 how this works out with onionbalance-based designs.

 Rev counters are there so that HSDirs (and other actors) cannot replay old
 HS descriptors. However, they are not really needed since now HS
 descriptors are only replayable for a day (before the blinded key gets
 refreshed), and also HSDirs could keep a replay cache of the descriptor
 assigned to a blinded key.

 If we decide to rip them off, the way to do it is in two painful steps:
 a) Remove rev counter checking from HSDirs, and do a replay cache or
 something.
 b) In the far future, when all HSDirs have upgraded to (a), rip out the
 rev counter code from onion services.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25552#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list