Let's get moving on NTS

[Gary E. Miller]

Yo Hal!

On Sun, 06 Jan 2019 15:22:32 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> Gary said:
> > Section 6 proposes a simple means to keep generating new short term
> > keys fomr old keys, so no need for further communication between
> > the NTS-KE and NTPD. Just once is enough.   
> 
> There needs to be coordination when keys change.

Only once, at the beginning.  Look at OTP.

I'm not arguing against coordination, just that are the lowest level
it is only required once, and initial configuration time.

> It might be possible to have both NTS-KE and NTPD use the same
> new-key recipe and the same time constant, but that seems like an
> invitation to get out of sync.

What was the last time OTP gave you a problem?  I use it all the
time, works great.

>  I think it will be cleaner to have
> one end in charge of keys and tell the other end when they change.

Cleaner yes, but less robust.  The Proposed RFC specifically worries
about how to rejey when the NTS-KE is down.

So, nice to have, but should not be required.

> We also have to consider how to get started and/or what happens when
> one end gets restarted.

Yes, let us start at the beginning.

> My straw man is that NTS is in charge of keys and NTPD will ask at
> startup and poll occasionally.

Not required by the spec, but having the NTS-KE in charge of the
keys was also my thought.  But NTPD can NOT be required to talk to the
NTS-KE at startup, that sort of thing is warned about in the Proposed
RFC.  The NTPD needs to be able to carry on for a long time on its
own.

If you can imagine a data server restart, they happen more than you
would expect, that would cause chaos.

> > The how could be as simple as a config file they share,   
> 
> > Then, if they both start with the same key, they roll forward,
> > forever, with no communication.   
> 
> That's communicating via the file system.

No, the file system is just storing the results of a communication.
The communication may be as simple as a phone call to an admin to
edit a config file.

> It's not a traditional
> config file that an admin edits.

Really?  NTPD puts the key in a config file that an admin edits, this
is jsut an extention of that.

>  It needs to get updated so keys
> aren't reused when the system reboots.

The keys MUST be reused on system reboots.  As required by the Proposed
RFC.  Requiring a data center to completely rekey on startup would
create chaos.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190106/ea5e3d16/attachment.bin>