Hi, > 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. Ah, thanks - that's helpful, > It's worse for the risk of guard compromise. > But it's better because it prevents the client being fingerprinted > using its guard set. Right, so rock or a hard place? =) > > 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 eventuality. However, it seems you don't like that idea - there seems to be some dissent among the Tor devs which approach is best for this situation. Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev