NTS keys as I understand them

Gary E. Miller gem at rellim.com
Mon Jan 14 21:48:48 UTC 2019


Yo Hal!

On Mon, 14 Jan 2019 13:30:03 -0800
Hal Murray <hmurray at megapathdsl.net> wrote:

> Gary said:
> > One is sufficient for that.  Cookie reuse is fine.  
> 
> Cookie reuse is fine in the sense that it should work.  But the whole
> tone of the draft is that they won't be reused.  There is only a
> minor note that says you can reuse them.

Yup, that is my point, cookie reuse is fine.

> I think we should follow the spirit of the draft rather than explore
> a corner case.

Seems to me that reuse is in the spirit of the draft.  And not a corner
case, a very simple basic case.  The sort of thing a minimal client
would do.

> > Yes, but then you have no spare cookies for when you DO lose 8
> > packets in a row.  It is pretty common to lose 8 packets in a row
> > on today's internet.  
> 
> How often do we lose 8 packets in a row when they are spread out at 1
> minute intervals?  (I have data in old log files but it will take me
> a while to dig it out.  I fixed a bug a couple of days ago.)

All the time if you are on Comcast or a cell phone.

> It might make sense to reuse a cookie during a burst.  That case can
> wait.

Why wait?  Seems trivial to me that it is a fine thing to do.  Not
heard any counterarguments.  And it is a trivial thing for the client
to do, why make bursts harder?

> Reusing cookies makes more sense in the static case where you aren't
> worried about tracking, a server or home PC rather than a laptop or
> smart phone. Again, that case can wait.

Design first, code second.  We are in the design phase, lets get it all
down first, then code.  Allowing cookie reuse can make for a simpler
client.

Why do you keep fighting it?  The NTPD needs to work either way, so
all we can do is allow the client to choose.

> > Sure we can.  Nothing in the Proposed RFC says the NTPD must
> > invalidate cookies.  As a practical matter maybe the NTPD needs a
> > config option for cookie lifetime.   
> 
> The cookie lifetime is the master key lifetime.

Uh, no.  The NTPD is free to keep cookies past the time that a
new master key is created.  Note the proposed standard only makes
suggestions on the cookie content, no more.

> Sure, the NTP server
> could remember old keys forever.  The intention is clearly that the
> client rotates cookies and that the server only remembers the current
> key and 1 old key.

I'm fine with that, is someone suggesting otherwise?  What are you arguing
for or against here?

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/20190114/ab1bb745/attachment.bin>


More information about the devel mailing list