<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 23, 2015 at 4:14 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any Noise handshake has initiator and responder roles, the responder<br>
would send the cookie if it's overloaded and wants to add a round-trip<br>
to prevent IP spoofing.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>I don't know whether they have a countermeasure for this beyond UDP<br>
port numbers.  You could add a random value in the initiator's message<br>
which is echoed by the responder.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Also, this cookie value can be learned via MitM.<br>
<br>
</span>I guess people just live with that risk.  There doesn't seem to be a<br>
better alternative.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>Doesn't seem that complicated - the client sends an initial Noise_IK<br>
message, and if the server wants the DoS countermeasure, it refuses to<br>
handle the request, and instead sends a cookie.  The client resends<br>
the request with the cookie, at which point the server accepts it.<br></blockquote><div><br></div><div>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...  </div></div>
</div></div>