Why do we need to send a challenge to a client on every request?
No, it is only the first time when connecting an onion and moreover this should be enabled only when the configured rate limit / antiDoS is reached. SO actually a client will be connecting to the onion like always: with no PoW. If the Intro Point reaches a configured limit, then, it starts challenging the client, only the first time, the first request to that onion.
Someone said that my design of adding an extra round to make the PoW step was bad, yes, we could use something unique to that circuit based on ntor.
BUT, what is better for performance? Is sending an extra cell better than computing PoW always? etc.
-If you add an extra step for PoW: you can enable it only when needed: 1) no DoS? client connects like always and do not make a PoW. 2) DoS? client receives a challenge and computes a PoW.
-If you do not add an extra step there is no dynamic way to enable or disable PoW. You bypass the extra step but the client needs to compute PoW every time. The only config aviable is service descriptor where onion can put the "enable pow" and client reads it and sends the PoW to I.P.
mmmm unless you wanna build something more complex...
On 20/6/19 15:41, Chelsea Holland Komlo wrote:
On 2019-06-20 00:19, Watson Ladd wrote:
On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo me@chelseakomlo.com wrote:
There are a couple approaches to consider.
POW via hashing goes for a relatively simple to implement approach. However, this incurs a high cost for all clients, and also environmental damage, per previous email.
Another approach similar to the above (but more environmentally friendly) can be Proof of Storage (or proof of space), as in https://eprint.iacr.org/2013/796.pdf
With both of the above approaches, there will be a tradeoff to what the cost is to deter a would-be attacker, versus the cost to real but bandwidth/cpu limited clients, such as on mobile platforms.
More involved approaches include anonymous blacklists/whitelists, blinded tokens, etc. Previous work has been done in this space, here is one example: https://crysp.uwaterloo.ca/courses/pet/F11/cache/www-users.cs.umn.edu/~hoppe...
Privacy Pass has already been integrated into Tor Browser. Perhaps work could be done to use it here?
An approach akin to Privacy Pass could be an option to avoid serving challenges to clients with each request (see reference to anonymous tokens above), but it cannot be a drop in fix, of course. Furthermore, an acceptable POW or POS scheme still needs to be selected, the tradeoffs of which we are currently discussing.
Better understanding the requirements of the system from George and David will help define which approach is acceptable given the tradeoffs. For example, I imagine accessing onion services should not be restricted to clients from a web browser. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev