Re: [Ntp] Antwort: Re: WGLC: draft-ietf-ntp-using-nts-for-ntp

[[e-mail]]

I would like to re-post parts of an old e-mail of mine from August of this 
year regarding Dave's "DTLS Lite for NTP" document (as posted by Harlan, 
on August 2nd), as I'm unsure whether my text ever made it to the list 
(posted it from my private account, can't see it on my work accounts) and 
it is kind of essential to at least my own dismissal of that document as 
an all-in-one solution, and of potential points that could be taken from 
it and applied to the NTS spec:

My main problem with the presented document remains the same from previous 
versions of it:
I find it hard to see what the reader is supposed to take away from it, or 
what kind of document it should be seen as. 

Scanning some of the parts where it does go into more detail, I have also 
found a few items that I think show major issues, at least one for each of 
the modes:

- Symmetric Mode: there seems to be no initial validation of which public 
key belongs to whom (such as externally validates certificates could 
provide). 
In this case, all the procedure does (at best) is to ensure that whoever 
I'm talking to initially is also the same entity I'm talking to later, 
which still allows anyone to pose as any entity initially. 
I find it doubtful whether this represents any improvement over just using 
the symmetric key security approach for this mode.

- Client/Server Mode: "The cookie is the hash of the client IP addresses 
concatenated with a server secret key using the selected hash algorithm". 
This is straight out of the Autokey playbook. It was clearly identified in 
2012 in S. Roettger's analysis of Autokey as one of the major issues and a 
complete showstopper regarding security.

- Broadcast Mode: Seems to use asymmetric signatures in a straightforward 
design. 
But we ruled this out years ago because we found it unclear that every 
device that potentially was going to be a broadcast server (or arguably 
even a broadcast client) was going to be able to do this without 
significant detriment to timestamp accuracy. 


Best regards,
Kristof