George Kadianakis desnacked@riseup.net writes:
juanjo juanjo@avanix.es writes:
Ok, thanks, I was actually thinking about PoW on the Introduction Point itself, but it would need to add a round trip, like some sort of "authentication based PoW" before allowing to send the INTRODUCE1 cell. At least it would make the overhead of clients higher than I.P. as the clients would need to compute the PoW function and the I.P. only to verify it. So if right now the cost of the attack is "low" we can add an overhead of +10 to the client and only +2 to the I.P. (for example) and the hidden service doesn't need to do anything.
Also see the idea in (b) (1) here: https://lists.torproject.org/pipermail/tor-dev/2019-April/013790.html and how it couples with the "rendezvous approver" from ticket #16059. Given a generic system there, adding proof-of-work is a possibility.
Another option would be to add the proof-of-work in the public parts of INTRO1 and have the introduction point verify it which is not covered in our email above.
Proof-of-work systems could be something to consider, altho tweaking a proof-of-work system that would deny attackers and still allow normal clients to visit it (without e.g. burning the battery of mobile clients) is an open problem AFAIK.
Here is how this could work after a discussion with dgoulet and arma on IRC:
1) Service enables DoS protection in its torrc.
2) Service uploads descriptor with PoW parameters.
3) Service sends special flag in its ESTABLISH_INTRO to its intro points that says "Enable PoW defences".
4) Clients fetch descriptor, parse the PoW parameters and now need to complete PoW before they send a valid INTRO1 cell, otherwise it gets dropped by the intro point.
All the above seems like they could work for some use cases.
As said above, I doubt there are parameters that would help against DoS and still allow people to pleasantly visit such onion services through an uncharged mobile phone, but this choice is up to the onion service. The onion service can turn this feature on when they want, and disable it when they want. And mobile clients could also disallow visits to such sites to avoid battery/CPU burns.
All the above seems likely, but it's significant work. We first need a proposal to discuss, and then there is lots of code to be written...