[tor-dev] Onion Service - Intropoint DoS Defenses

[George Kadianakis]

George Kadianakis <desnacked at riseup.net> writes:

> juanjo <juanjo at 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...