Tangle - cookie keys file

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> Where should we put the file used to store the key used to make cookies?  It 
> gets read at startup and updated daily.
> 
> Fedora and Debian put things like that in /var/lib/ntp/
> NetBSD and FreeBSD put them in /var/db/ntp/

Given that we don't have any intrinsic technical reasons to choose one
over the other, I'd say this: Linux has the bigger userbase, so Linux
wins.

It's not that I love popularity contests as a way of deciding
technical questions, but I think we can expect fewer issues filed if
we follow that heuristic.

> Can we and/or should we make the default file names OS dependent?

I recommend trying to avoid that.  Follow the Filesystem Hierarchy
Standard and let other OSes be their local packagers' problem.  We
can't really do better than that by trying to, anyway. Any allocation
we make will be wrong to someone; all we can do is minimize the
incidence of annoyed someones.

If you can think of any technical reason to prefer one of these
locations my majoritarian argument instantly goes poof.

> This gets tangled up with initialization and the config file.
> 
> What should the system do if it can't read the file?  Crash?  Blunder on in 
> no-NTS mode?  Make one?  ...

I think blundering on in no-NTS mode would be wrong unless NTS has
been explicitly disabled in the config.  An iron rule: Enabled
security measures should fail noisily, not quietly, so a human will
take action. And they should be enabled by default.

> If it crashes, where do we get the first one?

The fact that this question needs to be asked implies that the right
answer to the previous one is "Make one and log a warning".

> Do we ant to be able to run in no-NTS mode?  What does that mean?  We have nts 
> enable/disable in the config file.  It enables the NTS-KE server which also 
> needs cookies.

I think we do want to be able to run in no-NTS mode, at least for
testing purposes.  But this has to be an option hedged with warnings,
one a human must explicitly select.  Like a tinker variable because it
has the risk/benefit profile of a tinker variable.

In fact at one stage of my config design this *was* a tinker variable.

> Does it make sense to have a ntp server than supports NTS without having a 
> NTS-KE server to get the initial cookies?  Eventually, you should be able to 
> get the cookies from something like NST-KE server for a pool.  But is there 
> any reason for a system not to run its own NTS-KE server that will only send 
> you to itself?

No, I don't think there is any reason not to do that. This is one
reason I strongly applaud your implementation strategy of putting
NTS-KE service in ntpd itself.  I think it was the right,
complexity-minimizing architectural choice.

> Anybody have any good ideas on this area?

I hope mine seem good.  But I'm open to argument on all these points
except the iron law of "fail noisily".

You're taking the lead on NTS, so my position is that you generally
get to use your best judgment on questions like these and enact it,
unless I think you're making a bad enough decision that it *has* to be
reversed for the good of the project.  I would not do that casually
and consider such a scenario quite unlikely to occur.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.