Let's get moving on NTS

[Gary E. Miller]

Yo Ian!

On Sun, 6 Jan 2019 16:30:05 -0600
Ian Bruene via devel <devel at 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
	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/31d4efb1/attachment.bin>