[noise] DoS resistance

[Jason A. Donenfeld]

On Sat, Jul 18, 2015 at 2:58 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
> Is the issue how much amplification there is between client
> computation and server computation?  HandshakeIK lets the client
> calculate the first message once, then repeatedly send it to the
> server, triggering 4 DHs:
>
> HandshakeIK:
>   <- s
>   ******
>   -> e, dhes, s, dhss
>   <- e, dhee, dhes

Exactly. Adding the timestamp (as in other messages) prevents against
a replay attack disrupting a legitimate session, but it doesn't help
with the DoS. Also, even sending a packet of zeros will trigger a non
trivial amount of work on the server.

> Suppose the client spends the first RT just to retrieve the server's
> ephemeral public key.  I think you can rearrange things so the client
> can only trigger 1 extra DH for each re-send, or 3 server DHs per 2
> client DHs:
>
>   <- s
>   ******
>   ->
>   <- e
>   -> e, dhee, s, dhse, dhes
>
> You could also require the first message to be padded to a certain
> length, to equalize the costs between client and server further.
>
> That requires keeping session state on the server before
> authentication, which you also didn't want to do.  But maybe that's a
> tradeoff you have to choose between.

Shucks, yea, not a tradeoff I'm too jazzed up about. Session state on
the server actually leads to a more unfortunate DoS, since memory is
generally more scarce than CPU, particularly in kernel land.

>
> If you want to shift the costs so that the client has to do more work
> than the server you could do "client puzzles" where the 1st RT
> challenges the client to solve some hashcash type puzzle, but that
> probably doesn't belong in the Noise core.

The problem with hashcash, though, is then the server needs to keep
track of "spent" hashes, to prevent against replay. Or is there a
trick to avoid this?