[tor-dev] Proposal 247: Alternate Path Lengths

[Mike Perry]

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.

I am inclined to accept this risk, since really as you said it is not a
sure shot. You need a lot of connections before the S set is reused
enough to indicate it's the same client, and then even with each
subsequent individual visit all you have is probability bias, not a sure
sign. I'm inclined to think that this partial linkability leak is is
acceptable enough risk to say "Well yeah, lower security for better
latency. You're getting what you're paying for."

I'm also really expecting these low security addresses to be most useful
in P2P, where linkability is already kinda out the window (but can still
be maintained if the addresses are ephemeral/short lived).

We should keep thinking about other issues, because unless there are
other, additional problems with R&S, I don't think this one kills it.


One thing worth noting is that you definitely want separate vanguard
sets for high security and low security services, of course.  Prop#247
was already leaning towards separate vanguard sets for each service
service-side address, in Section 4.2. That seems excessive now for the
high security services, due to the addition of ephemeral hops, but
keeping the low and high sets separate is necessary, as you pointed out
with your other attack.


Here's another application-layer issue: if low security services exist,
then the application will need some way to differentiate them before
being induced to connect to them, especially repeatedly over time. For
example, Ricochet should forbid you from accidentally using a low
security onion address for a contact addr, and the browser should
probably forbid all low security HS addresses from being used as content
elements, unless the url bar is also a low security HS address. Both
apps should probably specifically generate low security addrs for
WebRTC/voice calls, though.

I think a similar argument could be made for also differentiating
RSOS/SOS addresses, post-224.

For these reasons, I'm still really liking the idea of using those spare
224 address bits to indicate HS security level (and to additionally
differentiate between RSOS/SOS). That would make it much easier for the
application to avoid being tricked into using weaker addresses in bad
situations. In fact, the Tor client could even default to forbidding the
use of them unless the application specifically turns on support.



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160121/aec39e96/attachment-0001.sig>