[tor-dev] Update on 259

[Ola Bini]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160406/b980f579/attachment-0001.sig>