On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs<br>
<matthias@urlichs.de> writes:<br>
><br>
>> Can anybody think of problems with this solution?<br>
><br>
> Well, the possibility of DOS if you set the counter too high,<br>
<br>
Correct me please, but skipping even many counter values should not be a problem at all. So do you mean DOS in case your hit a wrap around of the<br>
counter? IMO this can be easily prevented.<br>
<br>
If the <br>
TAI64/96 bit timestamp field (64-bit seconds count + 32-bit nanoseconds count) <br>
in WG handshake_init messages is used as a counter, then it seems sufficient to just use the 32-bit nano-cnt part for sequential increments after each handshake. Only the sec-cnt part needs to be saved with a +1 value (implicitly assuming nano-cnt saved as zero): during wg modprobe and also whenever the in-memory nano-cnt value got 80% exhausted. Reserving room for 800 000 000 handshakes (in non-reboot cases) before a new fs-write operation is needed. Given that just the handshake-required ECDH-Curve25519 takes more than a ms (eg 769 handshake/s measured on my intel notebook) calculation, that would happen at most once every 10 days. But realistically rather in terms of month or years. <br>
So in practice, a sec-cnt+1 value, now representing not secs but handshake counts x 1000000000) would only be saved during each system boot or wg init.<br>
<br>
<br>
> and the<br>
> possibility of replay attacks if you fail to save the last state when<br>
> you shut down comes to mind :)<br>
<br>
Where is that possibility? If you fail then you would send<br>
handshake_initiation messages with an already outdated timestamp field.  Exactly what now happens by default with non-HWC equipped devices after each reboot.<br>
<br>
<br>
><br>
> (Not saying it's not possible to create a workable solution, just that<br>
> it's not trivial and requires careful thought to not break the security<br>
> assumptions of the protocol).<br>
<br>
I agree,<br>
but looking at the recent discussion (how to secure NTP as a work around for for non-HWC devices) some of the assumptions made by the current approach seem already quite questionable to me right now. Like super-simple WG and firewall setup. Instead of two-lines documentation<br>
you will likely need 2 pages plus some references for further reading to other tools (like NTP) and also inherit related problems. That does not sound like the WG philosophy to me.<br>
<br>
/Axel<br>
<br>
><br>
> -Toke<br>
> _______________________________________________<br>
> WireGuard mailing list<br>
> WireGuard@lists.zx2c4.com<br>
> <a href="https://lists.zx2c4.com/mailman/listinfo/wireguard">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
><br>
<br>
<br>
-- <br>
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.