[tor-dev] Update on 259
tdruiva at riseup.net
tdruiva at riseup.net
Wed Apr 6 13:56:37 UTC 2016
On 04/06/2016 08:53 AM, Tania Silva wrote:
>>>>>> 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"
>>>> Oh, wow, I don't think failing closed is a good idea.
>>>> It means users that move around a lot (and clients which have a longer state history) could fail at some arbitrary time.
>>>> Why not simply continue to add guards that satisfy the restrictions?
>> Well, users that move around a lot will only have an expanded sampled
>> set if they move between several different networks that have severe
>> restrictions - but mutually exclusive such restrictions. And we would
>> only ever hit this fail closed if we can't find anything in the
>> sampled set that matches the current needed restrictions. If we keep
>> adding guards, the idea of the sampled set as a measure to minimize
>> exposure to too many guards fly out the window.
>> The problem really comes down to this - if you have a network that is
>> actively firewalling every guard that is not under their control, if
>> we keep expanding we will sooner or later be forced to use a guard
>> under adversary control. By failing closed, we can avoid that
> We thought in to have a minimum size for this set after been filtered .
> The minimum size of the sampled set after filtering out nodes based on
> client configuration (FILTERED_SAMPLED). Proposed value is ???.
> In order to expose less guards when we are expanding sample set, we
> thought in to have a maximum size before to fail.
> What do you think if this is a configurable value by user? (we can have
> as default if not provided)
> In order to guarantee a minimum size of guards after filtering, we
> expand SAMPLED_GUARDS until a limit. This fraction of GUARDS will be
> used as an upper bound when expanding SAMPLED_GUARDS. Proposed value is
> 1 -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 648 bytes
Desc: OpenPGP digital signature
More information about the tor-dev