NTS: config and initialization

[Gary E. Miller]

Yo Hal!

On Fri, 08 Mar 2019 15:17:40 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> Gary said:
> >>  So maybe master.keys?  
> > Works for me.  Hal?  
> 
> Seems misleading to me.  There is nothing master-ish about it.  It
> only lets you unlock a subset of the cookies associated with a single
> system.

It is what the Proposed RFC calls it, Section 6:

    "Servers should randomly generate and store a master AEAD key
    `K`. Servers should additionally choose a non-secret, unique value `I`
    as key-identifier for `K`."

I hate to use a different lexicon than the standard.

Got a better idea?

> > I care to reduce the vocabulary, and to make the vocabulary match
> > the Proposed RFC.   
> 
> Master isn't used in the draft.  The terms in the draft are K and I.

No.  See above.

> How about K-I.keys

I'm not a fan of uppercase in file names, excapt a few like README, TODO,
etc. where you need to catch the users attention.

Plus it is K, I and the start time so the rollover can be computed.

Maybe k-i-d.keys?  Does not exactly flow off the tongue...

> > Uh, say what?  How/when/where does ntpd create the master keys?  I
> > thought those were an input.  At least the initial master key(s).   
> 
> Nope.  ntpd makes up the keys, writes them to disk, and reloads them
> on restart.

Ah, as the Section 6 snippet says above.

> There is a proposal, hinted at in the draft and clarified in a
> message from Daniel to derive successive keys with a ratchet
> algorithm.

Which I am not a fan of.  If a server, like NIST, is doing 200,000
queries a second, then in a few days you get into large numbnbers that,
at least theoretically, challenge the cryptograpy.

But I could live with it if the cookies have a limited lifetime, like
a few days.

> The idea is that a NTS-KE server could support a
> cluster/pool by getting copies of the whatever-they-are-called files
> from the NTP servers it supports.

Or the other way around.  I would trust the pool NTS-KE server to
have a better random number generator than a bunch of random NTPD
servers.

> It could run the same ratchet
> algorithm so it could make cookies without needing to consult the
> server it picked.

Yeah, I'm not a fan of that.  I'd like the NTS-KE to talk to the
NTPD at least daily for a liveness check.

> (The cluster server would have a file per
> server.)

Or not.

> You could reverse it and have the NTS-KE server make the
> file and send it to the NTP server.

Which would be my preference.

And it all assumes way too much about how NTS-KE server and NTPD server
magically talk with no defined protocol.  let's not get into that
tarpit now.

> Plan B is to extend the NTS-KE protocol slightly to handle the
> cluster/pool case.  The individual NTP servers in the cluster/pool
> would also run a NTS-KE server.

Which negates the benefit of moving the crypto from the NTPD to the
NTS-KE.  I do not like that idea.

> The NTS-KE server for the
> cluster/pool would relay the KE request to the selected server.  The
> protocol would have to be extended to include C2S and S2C.

Ouch.  Too much to dislike, and way to early to talk about.

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/20190308/5e72f3c1/attachment-0001.bin>