Mike Perry <[email protected]> writes: > George Kadianakis: >> Mike Perry <[email protected]> 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. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
