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

From: Sharon Goldberg <[email-masked]>
Date: Wed, 6 Apr 2016 15:12:05 -0400

Miroslav, this is a good point.  But still one could rerun the KE from
first message in order to rekey, but stagger the runs as you describe
below.

On Wed, Apr 6, 2016 at 4:50 AM, Miroslav Lichvar <[email-masked]>
wrote:

> On Tue, Apr 05, 2016 at 02:19:45PM -0700, Hal Murray wrote:
> > Both the server and client can get rebooted at any time.  So either side
> can
> > 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 retransmission timeouts will
> be banging away.)
>
> 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
>
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: [email-masked]
Date: Thu, 7 Apr 2016 00:57:35 +0200

-----"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> wrote: -----

>To: Miroslav Lichvar <[email-masked]>
>From: Sharon Goldberg 
>Sent by: "ntpwg" 
>Date: 04/06/2016 20:29
>Cc: NTP Working Group <[email-masked]>, Hal Murray
><[email-masked]>
>Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Server seed key refresh
>
>Miroslav, this is a good point.  But still one could rerun the KE
>from first message in order to rekey, but stagger the runs as you
>describe below.  

Yes, the staggering would be desirable. I've discussed this with Kristof some time ago. The problem with this is - as far as I remember - that the server would have to save state, because if the server re-generates the cookie upon a client request the choice of the server seed would be a function of the provided KIV. This would have violated the paradigm to have the the protocol stateless on the server-side. However, if the advantages in introducing state at the server-side outweighs the disadvantage, we might change this paradigm.

Dieter

>
>On Wed, Apr 6, 2016 at 4:50 AM, Miroslav Lichvar
><[email-masked]> wrote:
>> Both the server and client can get rebooted at any time.  So either
>side can
>
>> 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.)
>
>
>