Mike Perry mikeperry@torproject.org writes:
George Kadianakis:
Mike Perry mikeperry@torproject.org writes:
George Kadianakis:
I have mixed feelings about this.
- If client guard discovery is the main reason we are doing this, I think we should first look into these guard discovery vectors individually and figure out how concerning they are and if there is anything else we can do to block them,
<snip> > > > > > > Hsdir post/fetch: > > 1. C - L - M - S - E - H > > 2. C - L - S - E - H > > 3. C - L - S - H > > > > Intro: > > 1. C - L - M - S - E -- I - S - M - L - H > > 2. C - L - S - E -- I - S - L - H > > *3. C - L - S -- I&S - L - H (* IP Intersection attack!) > > > > Rend: > > 1. C - L - M - S - R -- E - S - M - L - H > > 2. C - L - S - R -- E - S - L - H > > 3. C - L - R&S -- S - L - H > > > > What is R&S is here? Clients use static short-lifespan rendezvous points?
Yes. Similarly for I&S (which we should not do - it's bad in every variation of Vanguards).
I don't see any such problems with R&S though, since R is not associated with any publicly viewable information, I don't think it is as big of a problem. At best its a linkability risk for the client. But maybe I missed something.
Hmm, the only problem I can see here is that the R&S can link clients based on the L node. So for example, in the crazy edge case where only one client conncets to hidden services through R&S over L, then R&S could count "Ah this client has done 42 rendezvous through me in the past 5 hours". And if that's a ricochet client with 42 contacts maybe it's a selector. But I think this is a pretty far fetched example...
<snip>
If we only offered two security level options, I currently like HSDir#1+IP#1+Rend#1 for high security and HSDir#2+IP#2+Rend#3 for low security.
For the low security case, can we think of any reasons to decouple R&S in Rend#3, or to use Rend#2?
Another issue with Rend#3 is that the hidden service will be able to link client visits (for a Short while) using the client R&S as a selector.