Hi folks,
Like I did for prop#271, I've done some fixes to prop#247 when I did my recent reread. Here were the easy fixes: https://lists.torproject.org/pipermail/tor-commits/2017-June/123303.html
And below are the parts that I shouldn't just unilaterally fix without the authors of the proposal being involved somehow. :)
On Sun, Sep 13, 2015 at 04:07:30PM -0700, Mike Perry wrote:
With this new path selection, we force the adversary to perform a Sybil attack and two compromise attacks before succeeding. This is an improvement over the current state where the Sybil attack is trivial to pull off, and only a single compromise attack is required.
With this new path selection, an attacker is forced to do a one or more node compromise attacks before learning the guard node of a hidden service. This increases the uncertainty of the attacker, since compromise attacks are costly and potentially detectable, so an attacker will have to think twice before beginning a chain of node compromise attacks that he might not be able to complete.
These look like duplicate paragraphs? We should pick the one we like more, or merge them or something.
- As soon as the adversary is confident they have won the Sybil attack, an even more aggressive circuit building attack will allow them to determine the next node very fast (an hour or less).
Won the Sybil attack against what? There is a lot of "won the Sybil attack" in this proposal, but I worry that each time it means against different nodes or different hops and that's not specified. We should try to be clear what exactly the attacker is attacking each time we talk about an attack.
From the table in Section 3.2.1, it can be seen that this means that the Sybil attack will complete with near-certainty (99%) in 29*12 hours (14.5 days) for the 1% adversary, 3 days for the 5% adversary, and 1.5 days for the 10% adversary.
Sybil attack to achieve what?
4.1. Mitigating fingerprinting of new HS circuits
By pinning the middle nodes of rendezvous circuits, we make it easier for all hops of the circuit to detect that they are part of a special hidden service circuit with varying degrees of certainty.
The Guard node is able to recognize a Vanguard client with a high degree of certainty because it will observe a client IP creating the overwhelming majority of its circuits to just a few middle nodes in any given 10-18 day time period.
The middle nodes will be able to tell with a variable certainty that depends on both its traffic volume and upon the popularity of the service, because they will see a large number of circuits that tend to pick the same Guard and Exit.
And if any of the "exits" have an exit policy of reject *:*, that's a great hint too.
This same reasoning is also an argument for increasing the number of second-level guards beyond just two
Maybe you already did that, since it says 'four' above?
4.3. Denial of service
And, woah, your 4.3 is "Denial of service", and the 4.3 in git is "Long term information leaks", so my final bug report here is that the last sent version of this proposal (sent by Mike on 13 Sept) differs from the one in git (!).
I guess we should figure out how they differ, since people are going to arrive on Monday having read different versions of them.
--Roger