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

Mike Perry mikeperry at torproject.org
Sun Jun 3 00:08:17 UTC 2018

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180603/74b035b8/attachment.sig>

More information about the tor-dev mailing list