Yo Hal! On Fri, 08 Mar 2019 15:17:40 -0800 Hal Murray via devel <devel@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
g...@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
pgpoOEqhdaWCV.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
