[tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

[juanjo]

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 at 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/~hopper/faust-wpes.pdf
>> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev