Need for HW-clock independent timestamps

[Axel Neumann <neumann@cgws.de>]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
<matthias@urlichs.de> writes:
>
>> Can anybody think of problems with this solution?
>
> Well, the possibility of DOS if you set the counter too high,

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
counter? IMO this can be easily prevented.

If the 
TAI64/96 bit timestamp field (64-bit seconds count + 32-bit nanoseconds count) 
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. 
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.


> and the
> possibility of replay attacks if you fail to save the last state when
> you shut down comes to mind :)

Where is that possibility? If you fail then you would send
handshake_initiation messages with an already outdated timestamp field.  Exactly what now happens by default with non-HWC equipped devices after each reboot.


>
> (Not saying it's not possible to create a workable solution, just that
> it's not trivial and requires careful thought to not break the security
> assumptions of the protocol).

I agree,
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
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.

/Axel

>
> -Toke
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[-- Attachment #2: Type: text/html, Size: 2950 bytes --]