First round of my stupid questions about NTS

[Gary E. Miller]

Yo Hal!

On Thu, 17 Jan 2019 15:54:28 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> The NTP-server to NTS-KE-server is complicated.  Gary has proposed no 
> connection, start with the shared key in a file and keep the keys in
> sync by running the same update on both ends.  I think that could be
> made to work, but I'd prefer a connection.

Correction: I have made no recommendation, just noted at least two
ways exist to get the initial shared master key.

At least initially putting the shared key on a file is a bootstrap
to a full connection.

> A connection handles the case of multiple NTP servers for a single
> NTS-KE server and sets things up for the case of multiple NTS-KE
> servers for the same name.

And maybe more.  Maybe not.

> With a connection, we could avoid storing the master keys on disk.

Nope.  The last thing you want when you reboot a data center is for
all the NTPD to contact the one NTS-KE for new keys.

> Clients would have to rekey if the system rebooted.

Whcih also creates another rush.  Modern data center design is to
minimize initial setups as much as possible.

> We could restart
> NTP-server or NTS-KE-server as long as the other end stayed up and we
> arranged to send the keys in both directions.

well, you sorta need a key to do that, right?  Seems circular...

> There is another problem area: who makes the initial certificates.

Lets Encrypt, or similar.

> If the NTS-KE server makes them, then the admin has to keep the
> NTS-KE server and NTP server in sync.

A bad idea.

>  If the NTS-KE server gets them
> from the NTP-server, then we need a working connection from NTS-KE
> server to NTP-server in order for a NTP-client to get started.

Also a bad idea.

> I think the common case of both on the same system should be OK.  If
> the NTS-KE-server can't connect to the NTP-server the NTP-client
> probably can't either.  I haven't thought much about more complicated
> configurations.

I think the NTPD should initiate communications to the NTS-KE.

> > Delta will need an IANA public port assignment.  
> 
> The NTP port is assigned and unused for TCP.  I've been assuming that
> we will use that until somebody says otherwise.

The Proposed RFC saya otherwise.

> > I'm leaning towards an organization in which the NTS client code
> > lives inside ntpd; this would reduce deployment friction slightly.
> > Is there any scenario in which we'd want to run these pieces on
> > different hosts?   
> 
> Seems reasonable.  It might be nice to have them as separate programs
> until we get things going.  For example, we could write hack
> debugging programs to act as fake NTP or NTS-KE clients to figure out
> what the other end is doing and/or poke particular cases.

I don't see how a single NTS-KE/NTPD daemon prevents that.  Like gpsd,
just have the test clients link into the main ntpd library.

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/20190117/46bdd239/attachment-0001.bin>