Need for HW-clock independent timestamps

[Axel Neumann]

Am 16. Mai 2018 11:38:23 MESZ schrieb "Toke Høiland-Jørgensen" <toke at toke.dk>:
>Axel Neumann <neumann at cgws.de> writes:
>
>> On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
>> <matthias at 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.
>
>No I meant DOS if you fail to save state properly. I.e., I send seqno
>100000, lose my state, reboot, and re-initialise to seqno 100. I have
>now essentially locked myself out of the network until my seqno goes
>above 100000 again. Since I have no way of reliably detecting this
>condition, there is no straight-forward manual recovery possible.

Ok, then measures to mitigate this likelyhood are needed. But as said, it boils down to incrementing and saving  a number during each system boot. Don't you think thid can be done in a reliable way.

>
>>> 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.
>
>You'd need to not only save your own seqno, but also the last seen
>seqno
>from every peer. Otherwise you're vulnerable to a replay attack after
>rebooting. And if you lose that state you are, well, vulnerable to a
>replay attack after rebooting :)

With my understanding, the same issue exists right now. The peers only verify if a less or equal timestamp has been seen before from this peer. Peer timestamps are not recovered over reboots and also NOT related to its own clock or timestamps. As said in the other thread. Time discrepancy can be infinite as long as it increases monotonically per peer.

/axel


>
>>> (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.
>
>Oh, I totally agree that it would be good if a solution could be found
>to this. I'm just objecting to the assertion that "it's easy, just
>replace the timestamp with an increasing seqno".
>
>-Toke

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