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

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 23 Mar 2016 20:35:51 +0100

On Wed, Mar 23, 2016 at 01:53:35PM -0400, Sharon Goldberg wrote:
> On Wed, Mar 23, 2016 at 1:11 PM, Miroslav Lichvar <[email-masked]>
> wrote:
> > 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.

Per client, right?

> > 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?

My thought was that clients using longer interval would save more time
by having old timestamps authenticated.

If I understand the scheme you propose correctly, the client would
have samples from previous packets in the NTS initialization validated
when the last packet in the initialization is received. The question
is what the client could do with these extra samples. I guess they
could be useful to estimate the frequency error of the clock as ntpd
does in the freq state for instance. A client polling at 64s interval
would save more time with this than a client using 2s poll (iburst).

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.

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

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

> 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

---

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.
>

Sharon