Hi,

Interesting proposal.

Please see this:
https://lists.torproject.org/pipermail/tor-dev/2014-September/007517.html

And especially this reply:
https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html

It would be very nice if you could glue these into this proposal as well.

It looks interesting so I will try to get it included into the proposal in the next update.

It makes sense, but the hardest thing here is coming with the right
amount of bytes value so we won't end up building on average more
circuits than we were with the 10 minutes time dirtiness configuration.

Of course it will be something really hard but my first idea is to use an amount of bytes a little low than the average amount in ten minutes.

I just want to understand something clear so pointing it out, because it
reads "maximum amount of bytes...": the MaxCircuitSizeDirtiness counter
will count bytes read/write on a circuit by all streams attached to that
circuit, and as soon as threshold is reached the circuit will be marked
as dirty, but the circuit will be closed when all streams are idle,
correct? Like

If MaxCircuitSizeDirtiness is 10000 bytes (just for example)
I could download a file of 150000 bytes from a destination host:36455
over the same circuit, via a single stream, and as soon as that stream
is idle, count 150000 > 10000 --> mark circuit dirty, stop attaching new
streams to it? I think you thought of this but want to confirm.

Yes, the moment the circuit exceeds the amount of bytes established it will stop attaching new streams to it. But the attached ones will continue sending/receiving data until idle.

Looking forward to see some preliminary statistics. Please think of this
threat model:

- an attacker discovers the location of an onion service. He hijacks it,
but does not alter the content or the functionality of the service, in
order not to signal the discovery to its users and further deanonymize
as many users as he can.

- he starts serving useless noise on that services so the bytes limit
threshold is reached fast, forcing users to build circuits more often
than the time dirtiness method.

- the attacker also controls some hostile relays that could potentially
be picked in any new created circuit.

Do we increase the success changes for these kind of attackers? make it
harder for them ? Or does the game remain unchanged?

The time dirtiness cannot be gamed by the attacker because it is based
just on user's action (or inaction), but the bytes sent over the circuit
can. That is why it is there in the first place.

If this sounds bad, here are two crazy ideas you could take into
consideration when doing the numbers:
1. Put a hard limit per stream as in how much a single stream can count
to the MaxCircuitSizeDirtiness threshold in terms of %, if that is
exceeded the bytes in excess are simply discounted, so it becomes
impossible for a circuit to be marked dirty "by size" just by being used
by a single stream.
2. Make MaxCircuitSizeDirtiness random, a value between n and m, where m
cannot be greater than n * q, for *each* circuit.
3. Both 1. and 2.?

Either way, thanks for working on this - this area needs some attention
and I am sure we can do better.

I was thinking in the second option but I need more time to make sure this is fine.

I will update the proposal in the next weeks, thank you for your advices.

ffmancera.
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Reply via email to