Subject: Re: [TICTOC] [ntpwg] WGLC on NTS: Round trips for key exchange

From: Sharon Goldberg <[email-masked]>
Date: Wed, 23 Mar 2016 13:53:35 -0400

On Wed, Mar 23, 2016 at 1:11 PM, Miroslav Lichvar <[email-masked]>
wrote:

> On Wed, Mar 23, 2016 at 03:59:48AM -0400, Sharon Goldberg wrote:
> > * Roughly, the idea is to compute an incremental hash of all the
> > unathenticated timing messages running in parallel with the KE.
> > Then, once the KE completes and the client and server share a key,
> > this key can be used to MAC this incremental hash. In addition to
> > this, we would require the client *not* to update its local clock
> > until it has validated this MAC of the incremental hash. In other
> > words, the client collects timing samples while the KE is running,
> > but updates its clock only after the KE completes. If the KE
> > completes in 2 round trips, this might perform reasonably well.
>
> This is an interesting idea, but wouldn't the server have to save the
> incremental hash between client's requests? An NTP server normally
> doesn't keep any state for clients and when it does (e.g. for
> monitoring and rate limiting), it's all in a constant amount of memory
> to prevent DoS attacks on the server.

If an incremental hash is used, then it would require a constant amount of
memory on the server.

> Clients that would benefit most
> from having timestamps authenticated retroactively probably would be the
> ones that poll the server least frequently and are most likely to
> have their state on the server lost.

I'm not sure I understand this point.  If a client is querying
infrequently, why not just wait until the KE completes, and the key is
established, before sending timing messages that can then be authenticated
with the established key?   Why would you want to start a timing exchange
in parallel with the KE?

Sharon

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 24 Mar 2016 05:17:10 +0000

Miroslav Lichvar writes:

> There is also a question whether the client would really want to use
> any samples from the non-timing NTS exchanges as the packets are
> longer and asymmetric, creating an extra error in the measurements.

It depends on how they are implemented.  A longer period of time between
the T2 and T3 timestamps need not be a big deal.  It's also possible to
do quick NTP responses where the NTS message gets returned in a later
exchange.

H