Re: [Ntp] An NTPv5 design sketch

[Daniel Franke <[e-mail]>]

On Wed, Apr 15, 2020 at 3:20 AM Miroslav Lichvar <[e-mail]> wrote:
>
> That code will likely need to be updated to fix security issues.

So will the NTP code itself, not to mention the OS kernel and whatever
else your device is running. Different NTP implementations have had
serious security issues with widely varying frequency; so have
different TLS implementations. I'm not going to engage in arguments
about the precise quantity, severity, or inevitability of these
vulnerabilities; I'm just asserting the lack of a qualitative
difference in the historical need for patching.

> Crypto is hard. NTS
> requires other things that were not needed with plain NTP. It needs a
> full TCP stack and AES-SIV-CMAC. It needs certificates, NTS-KE servers
> and some naming for the servers (e.g. DNS). It needs a much more
> powerful CPU to be able to perform a TLS handshake in reasonable time
> and processing of NTP packets is orders of magnitude slower even with
> a hardware AES support. There is also the requirement on having a
> rough idea of current time in order to validate the certificates.
>
> For people who need to synchronize computers in an isolated network it
> is a lot of extra work. SNTP or NTPv4 may not be good enough for
> accuracy (unless they support correction fields).
>
> There are other authentication mechanisms with different tradeoffs
> that people might want to use.

You're mixing concerns about constrained devices with concerns about
isolated networks and system administration, which are two very
different spaces with different considerations, so I'll address those
separately.

Constrained devices: microcontrollers from the mid-range upward are
plenty capable of TLS and most of them explicitly advertise as much.
The ones smaller than that aren't designed for networked applications
at all; they're designed for like, tying a few pins from an LED or a
motion sensor together with a with a few pins on an I2C bus. The gap
in capabilities between being able to handle all of the network stack
except TLS and being able to handle TLS is tiny, and I assert that in
practice it's non-existent — because TLS is already so ubiquitous that
there's no market for a networked µC that can't handle it.

Isolated networks: TLS doesn't require certificates or DNS! X.509
supports IP-based SANs, and TLS supports PSKs, bypassing X.509
altogether. If today's software support for such options is lacking or
its UX is poor, remember that none of this is getting deployed
tomorrow; if we get this done in three years I'll consider it to have
gone smoothly. When we first decided on AES-SIV for NTS, there was
barely any support for that either. That situation changed because of
the interest that this WG generated.

> I don't see a single reason why NTS should be a requirement of NTPv5.
> It would help if you could explain why do you think it should.

NTPv5 (as I've sketched it) depends on NTS for more than just
cryptographic security; it's also version negotiation (NTS Next
Protocol), server discovery (Server and Port Negotation), and
anti-amplification (address-bound cookies). Making NTS optional would
require alternative approaches to all these issues. It would also
complicate the packet format and add landmines for implementers
(granted, already present in v4 NTS) around correct handling of
unprotected responses.