[tor-dev] Update on 259

[George Kadianakis]

George Kadianakis <desnacked at riseup.net> writes:

> [ text/plain ]
> Ola Bini <obini at thoughtworks.com> writes:
>
>> [ text/plain ]
>> Hey,
>>
>>> <snip>
>>>
>>> That's not very nice because the USED_GUARDS set that was created when
>>> ClientsUseIPv6 or FascistFirewall were on will have reduced diversity. Then
>>> even if we switch off those options, we are still stuck with reduced diversity.
>>>
>>> I'm not sure what's the right way to do this here!
>>>
>>> We could imagine having multiple USED_GUARDS sets, where we make a new set for
>>> each possible filter. This might be worth considering, but I imagine there will
>>> be technical difficulties. e.g. when a guard goes down, you need to update its
>>> state in all the USED_GUARDS sets that it's in. Also, a person who toggles the
>>> FascistFirewall option frequently, will end up using two different sets of
>>> guards all the time which is suboptimal.
>> Well, one thing you could do is hash the settings (and maybe also
>> reachable ports) and use that as a key to differentiate the different
>> USED_GUARDS. That would solve the problem, but might lead to a single
>> client using lots of different guards in different locations. Might
>> that be OK?
>>
>
> Hmm, it could be that in some cases the USED_GUARDS list of settings A would
> also work fine under settings B. For example, an 80/443 guard might be our top
> guard under vanilla settings, which would also work fine under FascistFirewall
> settings.
>
> In those cases (which are not all that rare), it would be suboptimal to use a
> different guardlist, since you are going to expose yourself to more guards than
> required.
>

On second thought, I think using a single USED_GUARDS list here should be OK
for now. That's also what Tor is doing right now, so this behavior can't be
worse than the status quo.

On this note, we should add a small "Discussion" section on the proposal and
briefly mention these issues that we might want to solve in the future, but we
don't know how now.

>>> > - Can we make the lists smaller?
>>> > Probably. Maybe a sampled set of 30 guards? Or 1.5%?
>>> >
>>>
>>> Plausible. However, if we take the filtering approach but use a small sampled
>>> guards list, it could happen that the list is not able to satisfy some of our
>>> filtering restrictions.
>>>
>>> e.g. maybe in our 30 guards there are no IPv6 guards at all, and the user just
>>>      turned on ClientUseIPv6. What to do now?
>>>
>>> This is important to understand, because currently there is no mechanism to add
>>> stuff to the sampled guards list if a restriction cannot be satisfied. So what
>>> will Tor do, if a user enables ClientsUseIPv6 _and_ FascistFirewall but there
>>> are no IPv6+80/443 guards in our sampled guards list?
>> Yeah, we talked about that yesterday. Our suggestion is to do
>> something like this:
>> - if the filtered/reduced sample-set contains less than X (5?) guards,
>> expand SAMPLED guards using the regular process.
>> - If SAMPLE guards reach SAMPLED_MAX (50?) size, we fail closed with
>> an error saying something like "your current network settings make it
>> impossible for us to safely choose an entry guard. If you really need
>> to connect under these circumstances, consider explicitly setting the
>> EntryGuards configuration option"
>>
>
> I share the same concerns as teor here.
>
> As you said, I think it's important to keep the property of restricting the
> total number of guards we connect to, as to avoid the attacks you mentioned.
>
> Of course, the above property also carries the inherent risk of potentially
> failing closed. For example, consider the unlikely scenario where _all_ the
> relays in your sampled set suddenly go offline while your network is fine.
>
> That said, we should be very careful of failing closed like that just because
> the user changed some torrc options and moved around a bit.
>
> I will try to think more about this problem and write something tomorrow or the
> day after.
>

I'm still not sure what's the right thing to do here.

The approach that you and Tania describe might make sense for now. I imagine
that we will want to tweak the exact numbers after testing in the real world.

I wonder if there is something smart we can do here...

Here is a non-smart thing we could do: We could prepopulate our sampled guards
list with all the possible guard types. So we include an 80/443 bridge and an
IPv6 bridge and an IPv6 bridge that is also on 80/443, and any other thing we
can think of. Unfortunately, this would greatly reduce the diversity of our
guard list since there can't be too many guards that are IPv6 and on 80/443,
and in the end most clients will end up using the same guards.

It might be a good idea to enumerate the guards for each possible filter we
will add, and then calculate their guard probabilities, to see how likely it is
to randomly choose a guard of that type. If we have filters were there is only
1% probability of picking a bridge of the right type, then these "your current
network settings make it impossible for us to safely choose an entry guard"
messages might appear more frequently than we would like.