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