> On 6 Apr 2016, at 23:08, Ola Bini <obini@xxxxxxxxxxxxxxxx> wrote: > > Hey, > >>> - OrPort vs DirPort >>> ORPort is used for regular circuits, while DirPort is used when getting directory information. We need to interpret reachable stuff >>> differently depending on the purpose. >> I'm not actually sure what the comment means here. > This was more for our own benefit. The OrPort vs DirPort distinction > has been a bit complicated so far. The comment basically means, when > we are looking up directory information, we should use the DirPort to > decide reachability and so on instead, correct? No, clients typically tunnel directory requests over the ORPort when they can. This is better for anonymity. But they will fall back to the DirPort in some circumstances. And relays use the DirPort all the time. >> Hm, are you talking about the guardlists here? What's the question? >> >> BTW, if we have the ability to do "ensure a min percentage of X in our sampled >> set", couldn't we just ensure a min percentage of dystopic guards in our >> sampled set? And forget about the two separate guardlists? >> >> In this case we can have the percentage value be the actual portion of the >> network that is dystopic guards. So if 20% of the total guard bandwidth is >> dystopic, we could ensure that at least 20% of our sampled set is >> dystopic". > Well, the problem is really that the idea of dystopic doesn't > necessarily make sense, since it's so dependent on the current network > position of the client. Our current thinking is to do away with that > concept as well. =) This would make things simpler, and would address many of my issues with the proposal. >> 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? It's worse for the risk of guard compromise. But it's better because it prevents the client being fingerprinted using its guard set. >>> - 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" 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? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev