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