Re: Need for HW-clock independent timestamps

[Axel Neumann <neumann@cgws.de>]

Am 16=2E Mai 2018 11:38:23 MESZ schrieb "Toke H=C3=B8iland-J=C3=B8rgensen"=
 <toke@toke=2Edk>:
>Axel Neumann <neumann@cgws=2Ede> writes:
>
>> On 13=2E05=2E2018 14:37, Toke H=C3=B8iland-J=C3=B8rgensen wrote:> Matth=
ias Urlichs
>> <matthias@urlichs=2Ede> 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=2E So do you mean DOS in case your hit a wrap around o=
f
>> the counter? IMO this can be easily prevented=2E
>
>No I meant DOS if you fail to save state properly=2E I=2Ee=2E, I send seq=
no
>100000, lose my state, reboot, and re-initialise to seqno 100=2E I have
>now essentially locked myself out of the network until my seqno goes
>above 100000 again=2E Since I have no way of reliably detecting this
>condition, there is no straight-forward manual recovery possible=2E

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

>
>>> 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=2E Exactly what now happens by default with non-HWC equipped
>> devices after each reboot=2E
>
>You'd need to not only save your own seqno, but also the last seen
>seqno
>from every peer=2E Otherwise you're vulnerable to a replay attack after
>rebooting=2E 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=2E The peers only v=
erify if a less or equal timestamp has been seen before from this peer=2E P=
eer timestamps are not recovered over reboots and also NOT related to its o=
wn clock or timestamps=2E As said in the other thread=2E Time discrepancy c=
an be infinite as long as it increases monotonically per peer=2E

/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)=2E
>>
>> 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=2E
>> Like super-simple WG and firewall setup=2E 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=2E That does not sound like the WG philosophy to me=2E
>
>Oh, I totally agree that it would be good if a solution could be found
>to this=2E I'm just objecting to the assertion that "it's easy, just
>replace the timestamp with an increasing seqno"=2E
>
>-Toke

--=20
Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet=
=2E