#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: ----------------------------+----------------------------------
Comment (by asn): WRT the replay cache idea of step (a) above, we probably do need a replay cache on the HSDirs, because there is a 24 hour window (before we change blinded pubkey) where HSDirs can replace the descriptors on other HSDirs with older versions of the descriptor. We probably want to avoid this and we should use a replay cache for this. The right way to use a replay cache here is to store the hash of the HSV3 descriptor on the replay cache. '''We should investigate''' whether we need to hash the whole descriptor, or the whole descriptor minus the signature (in case the signature is malleable and an attacker can tweak it to bypass replay cache). If we need to do the latter approach, we should add the right data in `hs_cache_dir_descriptor_t` as part of `cache_dir_desc_new()`. Implementation plan for step (a) above: 1) Introduce a global `replay_cache_t *hs_cache_replay_cache` in `hs_cache.c` next to `hs_cache_v3_dir`. We should index entries to this replay cache by blinded key, or maybe add an insertion timestamp so that we know when to clean it up. 2 In `cache_store_v3_as_dir`, remove the revision counter check, and instead query the replay cache for whether we already have seen this descriptor before. If we have seen this descriptor before we should treat it the same way we treat descriptors with a smaller or equal revision counter right now, that is, reject them and `log_info`. 3) We should clean up the replay cache when we are sure that the blinded key for a descriptor is now useless and will never be used by clients again. We should look in `rend-spec-v3.txt` to make sure when that is; probably at 24 or 48 hours or so. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25552#comment:3> 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