[tor-dev] Proposal 247: Alternate Path Lengths

[George Kadianakis]

Mike Perry <mikeperry at torproject.org> writes:

> George Kadianakis:
>> Mike Perry <mikeperry at 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.