Re: [tor-dev] Proposal 292: Mesh-based vanguards

2018-06-02 Thread Mike Perry
Ian Goldberg:
> On Mon, May 28, 2018 at 01:10:21PM +0300, George Kadianakis wrote:
> > 2.2. Path restriction changes
> > 
> >   In order to avoid information leaks and ensure paths can be built, path
> >   restrictions must be loosened.
> > 
> >   In particular, we allow the following:
> >  1. Nodes from the same /16 and same family for any/all hops
> >  2. Guard nodes can be chosen for RP/IP/HSDIR
> >  3. Guard nodes can be chosen for hop before RP/IP/HSDIR.
> > 
> >   The first change prevents the situation where paths cannot be built if two
> >   layers all share the same subnet and/or node family. It also prevents the
> >   the use of a different entry guard based on the family or subnet of the
> >   IP, HSDIR, or RP.
> > 
> >   The second change prevents an adversary from forcing the use of a 
> > different
> >   entry guard by enumerating all guard-flaged nodes as the RP.
> > 
> >   The third change prevents an adversary from learning the guard node by way
> >   of noticing which nodes were not chosen for the hop before it.
> 
> To be clear, you are proposing removing these path restrictions for
> which circuits?  All?  All HS-related?  All HS-related, but only if the
> new options are turned on?

Just if the new options are turned on.

We're still working out all the details about what to do with path
restrictions in general/default cases as part of Proposal #291 (see the
"Proposal #291 Properties" thread).

We may decide to change the vanguard restriction behavior as we finalize
the restriction story for all of the other cases.

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


Re: [tor-dev] Proposal 292: Mesh-based vanguards

2018-05-28 Thread Ian Goldberg
On Mon, May 28, 2018 at 01:10:21PM +0300, George Kadianakis wrote:
> 2.2. Path restriction changes
> 
>   In order to avoid information leaks and ensure paths can be built, path
>   restrictions must be loosened.
> 
>   In particular, we allow the following:
>  1. Nodes from the same /16 and same family for any/all hops
>  2. Guard nodes can be chosen for RP/IP/HSDIR
>  3. Guard nodes can be chosen for hop before RP/IP/HSDIR.
> 
>   The first change prevents the situation where paths cannot be built if two
>   layers all share the same subnet and/or node family. It also prevents the
>   the use of a different entry guard based on the family or subnet of the
>   IP, HSDIR, or RP.
> 
>   The second change prevents an adversary from forcing the use of a different
>   entry guard by enumerating all guard-flaged nodes as the RP.
> 
>   The third change prevents an adversary from learning the guard node by way
>   of noticing which nodes were not chosen for the hop before it.

To be clear, you are proposing removing these path restrictions for
which circuits?  All?  All HS-related?  All HS-related, but only if the
new options are turned on?
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


[tor-dev] Proposal 292: Mesh-based vanguards

2018-05-28 Thread George Kadianakis
Hello list,

here is the vanguard proposal that supersedes proposal 247.

It specifies the newest vanguard design which we've been working on:
   https://github.com/mikeperry-tor/vanguards

FWIW, the above project is still in experimental state and we are
expecting to launch it officially in the short term future. Until then,
feel free to experiment with it if you feel like it.

Check out the proposal and code and let us know if you have any
questions or feedback!

Thanks!

---

Filename: 292-mesh-vanguards.txt
Title: Mesh-based vanguards
Authors: George Kadianakis and Mike Perry
Created: 2018-05-08
Status: Open
Supersedes: 247

0. Motivation

  A guard discovery attack allows attackers to determine the guard
  node of a Tor client. The hidden service rendezvous protocol
  provides an attack vector for a guard discovery attack since anyone
  can force an HS to construct a 3-hop circuit to a relay (#9001).

  Following the guard discovery attack with a compromise and/or
  coercion of the guard node can lead to the deanonymization of a
  hidden service.

1. Overview

  This document tries to make the above guard discovery + compromise
  attack harder to launch. It introduces a configuration
  option which makes the hidden service also pin the second and third
  hops of its circuits for a longer duration.

  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 they might not be able to complete.

1.1. Tor integration

  The mechanisms introduced in this proposal are currently implemented
  partially in Tor and partially through an external Python script:
https://github.com/mikeperry-tor/vanguards

  The Python script uses the new Tor configuration options HSLayer2Nodes and
  HSLayer3Nodes to be able to select nodes for the guard layers. The Python
  script is tasked with maintaining and rotating the guard nodes as needed
  based on the lifetimes described in this proposal.

  In the future, we are aiming to include the whole functionality into Tor,
  with no need for external scripts.

1.2. Visuals

  Here is how a hidden service rendezvous circuit currently looks like:

 -> middle_1 -> middle_A
 -> middle_2 -> middle_B
 -> middle_3 -> middle_C
 -> middle_4 -> middle_D
   HS -> guard   -> middle_5 -> middle_E
 -> middle_6 -> middle_F
 -> middle_7 -> middle_G
 -> middle_8 -> middle_H
 ->   ...->  ...
 -> middle_n -> middle_n

  this proposal pins the two middle positions into a much more
  restricted sets, as follows:

   -> guard_2A
   -> guard_3A
  -> guard_1A  -> guard_2B -> guard_3B
   HS  -> guard_3C
  -> guard_1B  -> guard_2C -> guard_3D
   -> guard_3E
   -> guard_2D -> guard_3F

  Additionally, to avoid linkability, we insert an extra middle node
  after the third layer guard for client side intro and hsdir circuits,
  and service-side rendezvous circuits. This means that the set of
  paths for Client (C) and Service (S) side look like this:

 C - G - L2 - L3 - R
 S - G - L2 - L3 - HSDIR
 S - G - L2 - L3 - I
 C - G - L2 - L3 - M - I
 C - G - L2 - L3 - M - HSDIR
 S - G - L2 - L3 - M - R

1.3. Threat model, Assumptions, and Goals

  Consider an adversary with the following powers:

 - Can launch a Sybil guard discovery attack against any node of a
   rendezvous circuit. The slower the rotation period of the node,
   the longer the attack takes. Similarly, the higher the percentage
   of the network is compromised, the faster the attack runs.

 - Can compromise any node on the network, but this compromise takes
   time and potentially even coercive action, and also carries risk
   of discovery.

  We also make the following assumptions about the types of attacks:

  1. A Sybil attack is observable by both people monitoring the network
 for large numbers of new nodes, as well as vigilant hidden service
 operators. It will require either large amounts of traffic sent
 towards the hidden service, multiple test circuits, or both.

  2. A Sybil attack against the second or first layer Guards will be
 more noisy than a Sybil