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

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
-----------------------------------------------+---------------------------
 Reporter:  asn                                |          Owner:  dgoulet
     Type:  defect                             |         Status:  assigned
 Priority:  Medium                             |      Milestone:  Tor:
                                               |  0.3.4.x-final
Component:  Core Tor/Tor                       |        Version:  Tor:
                                               |  0.3.1.9
 Severity:  Normal                             |     Resolution:
 Keywords:  tor-hs prop224 034-roadmap-master  |  Actual Points:
Parent ID:                                     |         Points:  4
 Reviewer:                                     |        Sponsor:
-----------------------------------------------+---------------------------

Comment (by dgoulet):

 Replying to [comment:7 teor]:
 > > So as long as we get the new functionality into HSDirs before the next
 long-term-stable, the "far future" will just be a matter of waiting some
 months for intermediate stable versions to die out.
 >
 > But hang on, do clients require descriptors to have revision counters?

 So here is the fun part of this. Client do look at the revision counter
 when caching but only to decide if they have a newer one in their cache or
 not. Thus, a revision counter always to 0 for instance wouldn't affect the
 client cache.

 As for HSDir, they won't accept a descriptor with a revision counter that
 is lower or equal with the one they have in their cache. Meaning that 034+
 services will still need to put the revision counter in their descriptor
 for a while until <= 032 is phased out. Not putting the revision counter
 in the descriptor for specific HSDir is not trivial amount of engineering
 work.

 Now, this is where it gets messy. When decoding the plaintext part of a
 descriptor (where the rev. counter is), we hard require the counter to be
 in it (notice the `EQ(1)`):

 {{{
   T1(str_rev_counter, R3_REVISION_COUNTER, EQ(1), NO_OBJ),
 }}}

 Thus, as long as we have 032 and 033 HSDirs and clients on the network, we
 can't remove the counter from the descriptor else they won't be able to
 store/access 034+ services as every descriptor will fail to be decoded.

 Thus to summarize, the only thing we can do for now is make HSDir use a
 replaycache instead of revision counter, make client ignore revision
 counter and make the revision counter optional in the descriptor when
 decoding it.

 But we MUST make the service put the rev counter regardless, with the
 current mechanism, in the descriptor for a while else it will break client
 and HSDir <= 033.

 Or a more nuclear option, we bump the descriptor version to 4 which won't
 have the revision counter which will effectively make 034+ the birth of
 the onion service v4 :P...... not ideal ;).

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