[noise] Still working on DoS to no avail

[Jason A. Donenfeld]

On Wed, Dec 23, 2015 at 4:14 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
> Any Noise handshake has initiator and responder roles, the responder
> would send the cookie if it's overloaded and wants to add a round-trip
> to prevent IP spoofing.
>

Yes. But in WireGuard, sometimes during a re-handshake or a re-connection,
the initator and responder will wind up changing places with each other.
Therefore both responder and initiator are at some point accepting cookie
messages from the internet on UDP, which means each one can wind up
receiving bogus cookie messages.


>
> I don't know whether they have a countermeasure for this beyond UDP
> port numbers.  You could add a random value in the initiator's message
> which is echoed by the responder.
>

In this case, the UDP port numbers used are actually fixed. I guess the
random value idea works, or, I was thinking -- just incorporating the HMAC
of the original message into the encryption key.


> > Also, this cookie value can be learned via MitM.
>
> I guess people just live with that risk.  There doesn't seem to be a
> better alternative.
>

The status quo is indeed very subpar and not okay. If you assume MitM isn't
possible, then probably replay attack isn't either, which means a much
simpler scheme could be used. But I need to assume MitM is possible.


>
> Doesn't seem that complicated - the client sends an initial Noise_IK
> message, and if the server wants the DoS countermeasure, it refuses to
> handle the request, and instead sends a cookie.  The client resends
> the request with the cookie, at which point the server accepts it.
>

Yes, I know. It's not *too bad*, but it's not great. At this point, I've
accepted I'll need to do something like that. The problem is: is there
actually a good way of doing it? Even my Frankenstein situation previously
described has some issues...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20151223/3ede491c/attachment.html>