[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-relays] growing guard probability on exits (2020-10-15)
On Fri, Oct 16, 2020 at 10:49:43AM +0200, nusenu wrote:
> lets see when this graph stops growing
> https://cryptpad.fr/code/#/2/code/view/1uaA141Mzk91n1EL5w0AGM7zucwFGsLWzt-EsXKzNnE/present/
Sounds good. I think, based on your graph, that it is a coincidence that
we launched the "KISTSchedRunInterval=2" experiment right around this
time. That is, your graph shows that the consensus weights for whether
to use exit relays solely for exiting went from "100%, always do it" to
"a tiny bit less than 100%" *before* we changed the KISTSchedRunInterval
value.
I guess we will get another data point when we turn KISTSchedRunInterval
back to its default of 10ms, and (we hypothesize) it has no impact on
the weights.
> why is this relevant?
> It puts more entities into an end-to-end correlation position than there used to be
> https://nusenu.github.io/OrNetStats/#tor-relay-operators-in-end-to-end-correlation-position
Yep. I'm not worried in the short term here, since one of the features
of our guard design is that just because a relay suddenly has a chance
of being used as a Guard, that doesn't mean it becomes *your* guard. You
(your Tor client) already have your guard, and you'll be sticking with
it for the next few weeks probably.
So this question matters over the coming weeks or months, because clients
will be rotating to new guards and then they will have a tiny chance of
picking one of these exits as their guard, each time they rotate to a
new guard, which is typically an infrequent event.
*That* said: since the chance of picking any of these exits as your
guard is really tiny, I think that means they will have very few users
using them as guards, which puts them in a weird position. For example,
it means that if you're one of the very rare clients who picked an exit
as your guard, then your choice acts as a better fingerprint for you,
if you move around, and if there is an attacker that's in a position to
watch your local network in each new location.
I don't think we ever intended that edge case to happen, and it's kind
of an uncomfortable situation to be in.
I wonder if the right fix is: "if you have the Exit flag, you don't get
the Guard flag"?
I think it would mean that the tiny amount of excess capacity on exit
relays would get pushed into rarely-but-still-sometimes being used as
somebody's middle hop, which seems to me like a much better oucome.
> and it might also decrease exit traffic on exits when a tor client chooses an exit as guard
I think load on these exits would increase, not decrease. They're
already going to be used for exiting. That is, if you need an exit
for your circuit, you're going to use one. The impact of these weights
will actually *increase* traffic on exits, because they will be used
for exiting like normal (there's no choice) but *also* they will be
(very rarely at present, but still more than the 'never' from last week)
used in other circuit positions too.
--Roger
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays