Re: [Ntp] Fwd: DTLS Lite Security for the Network Time Protocol.

[Miroslav Lichvar <[e-mail]>]

On Tue, Aug 14, 2018 at 01:00:11PM +0200, Kristof Teichel wrote:
> On Tue, 14 Aug 2018 at 10:03, Miroslav Lichvar <[e-mail]> wrote:
> > I think there is also still the issue with replays able to cause a
> > denial of service. A proposal for securing the symmetric mode needs to
> > include a mechanism that will prevent such attacks, as the on-wire
> > layer cannot do that on its own.
> 
> Fair enough.
> But couldn't this be fixed by adding a few nonces in extension fields (and
> arguably improved even just by using the timestamps as a half-baked
> replacement for nonces)?

I guess it could be as long as a peer can get a number of nonces
without changing the state of the other peer and something (based on
crypto?) guarantess that nonces cannot be reused.

It probably has to be separate from the normal polling in the
symmetric mode, where only one request per poll can have a response.
The protocol needs to work even when the peers use uneven polling
intervals.

> > - Broadcast Mode: Seems to use asymmetric signatures in a straightforward

> Depending on the device, asymmetric signatures are not necessarily limited
> to a few milliseconds though.
> I remember that we concluded that a weak embedded processor could be fully
> busy processing a signature for an amount of time sufficient to disturb
> other operations. Or fail completely - depending on how pessimistic one is
> regarding the weakest hardware involved.

Oh, I see. Maybe a multithreaded implementation would mitigate that?

> Does interleaved play well with broadcast? I have never thought about that.

I think it works well. It's actually a bit more secure that the basic
broadcast mode as clients can check for missing messages.

> It does seem to me like the timestamp-as-sequence-number (in combination
> with signatures) might be adequate against strictly only replay attacks.

As long as everything works as expected, it could work. The trouble
is with various failures, e.g. bad RTC battery and server booting in
1970, which NTP clients may interpret as 2106, a GPS firmware issue
(week overflow), successful attacks on the server, etc. IMHO the
protocol should be immune to such failures.

-- 
Miroslav Lichvar