[tor-dev] Proposal 247: Alternate Path Lengths

[Mike Perry]

While discussing proposal 247 with George yesterday, we realized that we
still get security benefit from additional ephemeral hops beyond the
vanguards themselves.

Recall the high-level 247 path design is:

  C - L - M - S -- S - M - L - H

Where:
  C = Client
  L = Long lived Layer1 guard
  M = Medium lifespan Layer2 guard
  S = Short lifespan Layer3 guard
  H = Hidden Service (or hsdir)
  E = Ephemeral Hop (used below)
  I = Intro Point (used below)
  R = Rend Point (used below)

The benefit to just one more hop is easiest to see in the Introduction
Point case, where George and I reasoned that it probably is a good idea
to pick an intro point that is not the same as the Layer3 (S) set,
otherwise the hidden service is effectively publishing its Layer3 guards
in its descriptor, and using those same nodes to connect to rendezvous
points. Clients probably also do not want the multi-visit linkability of
using their layer3 vanguards to directly connect to an HS intro point.
This means the intro circuit becomes:

  C - L - M - S - E -- I - S - M - L - H

Similarly, in the rend case, hidden services probably do not want to
expose their Layer3 (S) guards quite so easily to a client's chosen
Rendezvous Point, and again, the client probably does not want to use
their Layer3 (S) guards as its Rendezvous point, to avoid visit
linkability. This means we again have 8 hops for rends:

  C - L - M - S - R -- E - S - M - L - H


Unfortunately, this is starting to get ridiculous. While there are clear
security benefits here, I think 8 hops is definitely at the point where
we can forget about voice and other interactive traffic behaving
reasonably. So what could we cut, if we wanted to?

Well, going back to the Prop247 threat model, we want the adversary to
perform at least two attacks: a Sybil and one or mode node compromise
attacks. So maybe we can (in some cases, or optionally?) eliminate the M
nodes from the path. Since the linkability risks may be acceptable for
some applications, maybe we can also optionally allow clients or servers
to omit the ephemeral hop. This basically gives us three options for
path lengths. Let's consider each path type:


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


Looking at these, we can see that we sacrifice the middle guards in the
second option, which will come at the cost of one less compromise attack
(but still the need to compromise the long-lived guard). We also lose
the unlinkability in the third option, and this actually bites us in
Intro 3: the hidden service L guard can perform a long-term intersection
attack, watching for published intro points and matching that to the
circuits that H makes to them. So that path length probably should not
be used.

But what about the others? Especially that Rend case? I really like the
security properties of the full 8 hop paths, but it seems to me that for
highly-interactive applications, we can provide the option for users to
give up some of the unlinkability in exchange for that 4 hop circuit,
which might actually allow for e2e hidden service voice and video to
have a shot at working. Are there any risks with paths this short for
that case?

Does it make sense to provide users with these different path length and
latency options? I'm thinking that the service could list its preferred
path length in its hsdesc, and the client could override that as it
chooses (either for more or less security). Is that dangerous? We were
already considering letting users choose their guard set sizes. Why not
path lengths also (or instead)?


-- 
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/20160120/25580615/attachment.sig>