#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs