NTS keys as I understand them

Gary E. Miller gem at rellim.com
Mon Jan 14 20:57:19 UTC 2019


Yo Hal!

On Mon, 14 Jan 2019 12:45:58 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> > It is actually allowed to re-use cookies, specifically if it wants
> > to avoid that re-keying.  Whether that's a good idea is debatable,
> > but the server doesn't know either way and the decision is up to
> > the client.   
> 
> Right.
> 
> I think we should make a "no reuse" decision.

The Proposed RFC says reuse is OK until the NTPD returns a NACK.

> We want that option
> for no-tracking.

Maybe an option for the client, the NTPD does not care if it is tracked.

>  We can't just keep reusing the first cookie we get
> since the master key will get updated occasionally.

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.


> Next time somebody is editing, please add a no-reuse note at the
> bottom.

I'm all for a note, but we disagree on what it should say.

> > BTW, the number eight is not arbitrary: that is exactly the number
> > of packets a burst poll would use.   
> 
> The normal case is that the client gets back a response before it
> sends the next request in the burst, so it only needs 1 cookie to
> start with.

And it could use the same cookie 8 (n) times.

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/49e272cd/attachment.bin>


More information about the devel mailing list