Re: [tor-dev] The case for Tor-over-QUIC

[Rob Jansen]

Thanks for the detailed write-up Mike! Theoretically, moving to QUIC seems 
great; it seems to solve a lot of problems and has enough advantages that we 
could just run with it.

I'll reiterate some of my primary concerns that I gave in Rome:

 - I think it would be a mistake to push forward with such a significant change 
to Tor's transport layer without significant testing and experimentation. We 
have tools that allow us to do full-network-sized experiments (Shadow), and we 
have interested researchers that want to help (including me).

 - However, I am much less optimistic than you that it will just work and 
instantly improve performance. You mention that Google has done lots of tests, 
but my guess is they test in environments that look like the Internet - i.e., 
fast core and slow edges. Do we know how it would perform when the path 
contains additional 6 edges sandwiching 3 potentially low bandwidth Tor relays? 
Tor is a significantly different environment than the Internet; for example, an 
end-to-end congestion signal in Tor will take orders of magnitude longer to 
reach the client than in traditional networks.

 - Because of the above, I'm not sure that an end-to-end design is the right 
way to go. As I mentioned, we have simulators and researchers, so we should be 
able to learn more and make a more informed decision before committing to a 
design that will be difficult to change later.

 - We should be sure to pay close attention to how this will affect emerging 
networks and applications, e.g., mobile devices and onion services.

 - The DoS attacks will change form, but I don't think they will disappear. I 
think it would be wise to understand how DoS might change, which is much easier 
once we have a design to analyze. Your summary helps with that.

I think it would be worth including R effort to investigate these issues in 
any proposal that gets written.

Cheers,
Rob

> On Mar 23, 2018, at 7:18 PM, Mike Perry  wrote:
> 
> In Rome, I held a session about network protocol upgrades. My intent was
> to cover the switch to two guards, conflux, datagram transports, and
> QUIC. We ended up touching only briefly on everything but QUIC, but we
> went into enough depth on QUIC itself that it was a worthwhile and very
> productive session.
> 
> Our notes are here:
> https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/FutureTorNetworkProtocolUpgrades
> 
> I wanted to give a bit of background and some historical perspective
> about datagram transports for Tor, as well as explain those notes in
> long form, to get everybody on the same page about this idea. With
> the forthcoming IETF standard ratification of QUIC along with several
> solid reference implementations (canonical list:
> https://github.com/quicwg/base-drafts/wiki/Implementations), I believe
> we are close to the point where we can finally put together a plan (and
> a funding proposal) to undertake this work.
> 
> Consider this mail a pre-proposal to temperature check and solicit early
> feedback about a Tor-over-QUIC deployment, before we invest the effort
> to deep dive into the framing, protocol, and implementation details that
> will be necessary for a full proposal.



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

Re: [tor-dev] Setting NumEntryGuards=2

[George Kadianakis]

Mike Perry  writes:

> [ text/plain ]
> Back in 2014, Tor moved from three guard nodes to one guard node:
> https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
> https://trac.torproject.org/projects/tor/ticket/12206
>
> We made this change primarily to limit points of observability of entry
> into the Tor network for clients and onion services, as well as to
> reduce the ability of an adversary to track clients as they move from
> one internet connection to another by their choice of guards.
>
> At the time, I was in favor of two entry guards but did not have a
> strong preference, and we ended up choosing one guard. After seeing
> various consequences of using only one entry guard, I think a much
> stronger case can now be made for bumping back up to two.
>
> Roger suggested that I enumerate the pros and cons of this increase on
> this mailing list, so we can discuss and consider this switch. So here
> is my attempt at that list. Let's start with a more in-depth recap of
> the one-guard arguments, along with some recent observations that change
> things.
>
>
> Arguments for staying with just one guard:
>
> 1. One guard means less observability.
>

Hello!

Here is some small analysis of Sybil resistance on 1-guard vs 2-guards.

I think this analysis is important even given the #14917 issue, since we
could defend against that by lifting those particular path
restrictions. I agree that's not ideal, but IMO it's definitely
something we should consider as part of a thorough analysis, since by
solving #14917 correctly we could still maintain connection to just
1-guard (assuming it's a stable node).

===

So on to Sybil resistance analysis:

For a 5% bandwidth adversary and a single guard, an attacker would have
50% chance to Sybil your G1 (i.e. deanonymize you) after 14
rotations. For a 3.5 month rotation frequency, this means that you would
expect your guard to be uncompromised by Sybil's for about 4 years. For
a 10% adversary you need 7 rotations for 50% so that's 2 years.

Now if we go to two guards, a 5% adversary would need 2 years to Sybil
your G1, wheras a 10% adversary could do that in 1 year.

All the above numbers are assuming a completely stable guard node, that
you only switch because its lifetime expired and not because of
reachability issues etc. So in the real world, the actual guarantees are
probably lower.

In general, I obviously feel more comfortable with the single guard
results, but also the dual-guard results are not so bad.

===

Now with regards to engineering, here is also something to be said about
how the prop271 algorithm will handle NumEntryGuards=2:

IIRC, the way it's currently handled means that if any of the two first
primary guards is down, the algorithm will skip that and choose between
the two next available, potentially going into the third primary guard
in the list [see how select_entry_guard_for_circuit() uses
get_n_primary_guards_to_use()]. This might not be ideal, and perhaps we
should tolerate some small unstabilities of the primary guards so that
we don't get to expose ourselves to even more guards...

Also, we need to look at how
guard_selection_get_err_str_if_dir_info_missing() will work after we
increase NumEntryGuards, since that function is what caused #21969, and
we should make sure that it's not gonna get more annoying if we bump up
the number of guards.

That's it for now! :)

Cheers!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev