Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Miroslav Lichvar <[e-mail]>]

On Tue, Jun 01, 2021 at 02:48:32PM +0200, Heiko Gerstung wrote:
> > Am 01.06.21, 14:01 schrieb "Miroslav Lichvar" <[e-mail]>:
> > Can you please elaborate? My (limited) understanding of DTLS is that
> > it would address the attacks. It has a 48-bit sequence number to
> > protect against replays and client authentication comes from TLS.
> 
> I understood that you want to use DTLS to exchange the symmetric keys used to calculate the ICV of the unencrypted event messages. This unfortunately does not address the replay/amplification vulnerability of the unicast negotiation protocol itself, it just protects against replaying the DTLS messages.

The idea is that DTLS protects everything except the sync and delay
request messages. The unicast negotiation would be protected, of
course.

> I most probably know much less about DTLS than you, Miroslav. For example, I do not know whether this requires asymmetric cryptography in every message or just at the beginning in the handshake. However, I am pretty sure that DTLS can be used to securely exchange the symmetric keys instead of using TLS in the NTS-KE phase. 

DTLS is just a datagram-based version of TLS. Asymmetric crypto is
needed only on start. Performance would certainly not be an issue. I
suspect you are already reinventing some of its wheels, like the
replay protection.

> As I tried to explain earlier, our intention with this draft was to stay close to NTS4NTP to enable implementors to re-use code and allow users to combine the required infrastructure for NTS4NTP and NTS4UPTP. I fully agree that other protocols and security mechanisms would do the trick as well, but I believe that the name "Network Time Security" indicates that it has a good chance of being a better fit for securing a network time sync protocol. And, according to our research and our experience regarding network time synchronization, we came to the conclusion that this is the case for unicast PTP. 

Ok, if you need as much of NTS4NTP as possible and at the same time
keep accuracy provided by hardware timestamping as is supported in
current hardware, I think the solution is simple: NTS4NTP over PTP.

You can wrap NTP messages in a PTP event message to get hardware
timestamps and keep all the benefits of NTS4NTP. It seems your plan is
to provide NTS4NTP in any case. Do you see any disadvantages?

This would be a very short draft and it would be useful even for
plain NTP without NTS. I think I'll give it a shot.

-- 
Miroslav Lichvar