[tor-dev] [Discussion] 5 ^H 3 hops rendezvous circuit design

[Zack Weinberg]

On 02/11/2014 11:53 PM, Paul Syverson wrote:
> The biggest concern is that no matter how you handle the commitment
> and the size of the flexible set, you make it fairly easy for a HS
> simply following this protocol precisely and with just the resource of
> a handful of other nodes (n) in the network to identify the client
> guard with certainty each time. (If he owns less than n, it becomes a
> likelihood rather than a certainty each time. Alternatively if he owns
> a few ASes or IXPs he could accomplish similar results with a judicious
> choice of the network location of all n.) Given the push
> elsewhere to use single guards for long periods, this makes guard
> nodes all the more likely to face subpoena or other forms of attack
> since the argument that this is a successful strategy to locate
> clients of interest is greatly strengthened. Since the HS can choose
> two hops that it does not object to, the client should be similarly
> protected, i.e., four relays in the circuit overall.
> 
> The other big concern is that this looks like there are many places
> to DoS or resource deplete the hidden service. Earlier designs kept
> per introduction connection state for the HS to a minimum. There may
> be ways to reduce that, but it is an important consideration.

So I have to say that I'm increasingly skeptical about the value of
guards in general, and in this specific case - where both endpoints are
emitting nothing but Tor protocol - I'm not convinced guards add
anything at all, because *even if* both sides happen to pick malicious
entry points that are controlled by the same adversary, the traffic will
be indistinguishable from middle-relay traffic!  ... Except, I suppose,
by traffic correlation to recover the flow and realize that the
malicious relays are in positions 1 and 3, which in turn means each is
talking directly to an endpoint.  And then they can do cross-flow
correlation and figure out which end is the hidden service.  However,
this kind of long-term correlation attack is *easier* for an adversary
that controls enough stable nodes that it has a reasonable chance of
getting picked as a guard by at least one party.  See above skepticism.

That said, these are both really good points, and together, may kill the
whole concept. :-(  I wonder if we can formalize the problem enough to
prove one way or another whether you really must have at least four hops?

(Four hops is what I2P uses, with two chosen entirely by the client and
two entirely by the server; but there appears to be nothing to guarantee
that a malicious peer can't connect directly to its counterparty's
two-hop chain, sacrificing some of its own anonymity but getting closer
to the counterparty.  I did just argue that that shouldn't matter,
though...)

zw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140212/a8604e2f/attachment.sig>