Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh

From: Hal Murray <[email-masked]>
Date: Tue, 05 Apr 2016 14:19:45 -0700

[email-masked] said:
> But yes, if we refrain from the periodic refresh we could merge the second
> and third round in the key exchange and additionally we would not have the
> situation that all clients need to refresh
>  their cookie because the server refreshed the server seed. But, of course,
>  we would need to explain why we neglect the must requirement in RFC 7384. 

Would it simplify the description and/or implementation if things were 
collapsed to two rounds?

Both the server and client can get rebooted at any time.  So either side can 
force a rekey by starting over.

If the server is going to have performance problems with rekeying, it will have the same sort of problem when it gets rebooted.  (Maybe worse since all the buggy implementations with short retransmission timeouts will be banging away.)

-- 
These are my opinions.  I hate spam.

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

---

From: Sharon Goldberg <[email-masked]>
Date: Wed, 6 Apr 2016 04:43:25 -0400

Hal makes a good point. The rekeying mechanism could be to restart the KE
from the first message.  Since anyway NTS has to be able to deal with the
client or server being rebooted, and rekeying should be infrequent.

On Tue, Apr 5, 2016 at 5:19 PM, Hal Murray <[email-masked]> wrote:

> If the server is going to have performance problems with rekeying, it will
> have the same sort of problem when it gets rebooted.  (Maybe worse since
> all the buggy implementations with short retransmission timeouts will be
> banging away.)
>
>
> --

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 6 Apr 2016 10:50:31 +0200

> force a rekey by starting over.

I think the server can save the seed to a file and avoid having
clients to reinitialize NTS when it's restarted. In such case NTS
requiring periodic refresh of the seed would make sense. 

The clients might want to save their cookies too and skip the NTS
initialization.

> If the server is going to have performance problems with rekeying, it will have the same sort of problem when it gets rebooted.  (Maybe worse since all the buggy implementations with short retransm…

If the server is expected to have a large number of clients, it can
use multiple seeds and refresh them slowly one by one to spread the
extra CPU load.

-- 
Miroslav Lichvar