[tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul

[Roger Dingledine]

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.

>   3. 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