Yo Ian! On Sun, 6 Jan 2019 16:30:05 -0600 Ian Bruene via devel <devel@ntpsec.org> wrote:
> On 01/06/2019 02:55 PM, Gary E. Miller via devel wrote:
> > Seems to me that Section 6 of the proposed RFC defines this pretty
> > well. Once you can figure out who Clarlie (NTPD) and Delta (NTS-KE)
> > are.
>
> Partially. It gives an example of a way to do it, but no protocol or
> message scheme; just what the cookies could look like. It is missing
> the primary piece that you want in that section of the design.
Yes, that what is vaguely outlined, the how totally ignored.
Which I mentioned late in my email. The how could be as simple as a
config file they share, or as comlicated as a reatl time load balancing.
Just a config file seems the way to start.
> > Hardly qualifies as a transaction as there is no reciprocity (See
> > the dictionary). In the dark past, either the NTPD told the NTS-KE
> > what keys to use, or vice versa. Not even a need for an ACK.
>
> Fair enough, I'm not versed in the terminology here.
I just used Websters. Maybe best to google terms before using them.
> >> "It's whatever is needed to verify the cookie from Alpha."
> > Yes, the blob as defined in Section 6.
> >
> >> Whatever needs to be communicated on that channel it can't be
> >> verifying cookies and also be "only an occasional ???". Verifying
> >> cookies means every single ntp packet that comes in to Charlie has
> >> to be checked with Delta.
> > Nope. Reread the Proposed RFC. NTS-KE and NTP agree before hand on
> > some long lived keys to use.
Yes, exactly. So I am not sure what you are disagreeing about. That
agreement could be a simple config file with the initial key material.
> > They actually don't need to 'agree'.
> > Either the NTS-KE tells the NTP, or vice versa. Maybe no need for
> > any negotiation. Then use them for hours, days, weeks or months.
> >
> > 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.
> >
> > Not to say that it can't, or shouldn't, get a bit more complicated,
> > but it is not required.
>
> Verifying /cookies/ would be NTPD asking NTS-KE for the data the
> cookie represents.
Which luckily is NOT, ever, required. Both the NTPD and NTS-KE derive
that data from the same seeds.
They start with a shared key, and never need to communicate again. Think
of it like how OTP works. Start with a shared secret, then roll forward
forever.
> The only reason to do that would be if NTPD never
> handles key storage / creation / ratcheting / etc itself and offloads
> all of that to NTS-KE.
Or, they store / create /ratchet in parallel, with no further
communication, using the same algorithm, Once again, look at OTP.
And look at section 6 of the proposed RFC:
"However, the task can be accomplished without the need for central
key-management infrastructure by using a ratchet, i.e., making each
new key a deterministic, cryptographically pseudo-random function of
its predecessor."
Then, if they both start with the same key, they roll forward, forever,
with no communication.
And be careful, here I just argue what the Proposed RFC requires, not
the best possible arcitecture. First: see what we need, Second: add
cool stuff.
> That is the one option that has been universally shot down as bad.
I'm not sure what option you refer to. Best in discussions like these to
keep indirection to a minimum.
> I've pushed an update to nts.adoc.
I'll look for it, but my attention is elsewhere today.
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
pgpOeJAdv7vl6.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
