Re: [Ntp] Pool and DNS

[Hal Murray <[e-mail]>]

[e-mail] said:
> I think you're basing this on a couple of false assumptions. First, I  don't
> know where the cookie lifetime of one day comes from. That's not specified
> in RFC 8915. In most cases, we would expect the cookie to be valid as long
> as the cookie encryption parameters shared between NTS-KE server and NTP
> server are not changed. This could potentially be a very long time.


Interesting.  Thanks for bringing up this issue.

The key for the cookies needs to rotate occasionally.  I'm not enough of a 
crypto geek to explain it.  There is a limited amount of data you can use with 
the same key before bad things happen.  How much depends on the algorithm.

I think there was some discussion on this list, I don't remember the details.  
One day seemed like a reasonable number.

RFC 8915, section 6, Suggested Format for NTS Cookies, says:
    Servers should periodically (e.g., once daily) generate a new
    pair '(I,K)' and immediately switch to using these values for
    all newly-generated cookies.

So one day is what I used in NTPsec.  (and my thinking)

The rest of that paragraph discusses keeping old keys, plural, but doesn't say 
anything about how many to keep.  One seemed like enough to me.  That provides 
a minimum of 24 hour lifetime and ntpd has a default max polling interval of 
1024 seconds.  I didn't consider any cases that would stash cookies for a long 
time.

You seen to have made the opposite assumption - that a server should support 
cookies for a long tlong ime.

It's easy to save a few old keys.  We should probably agree on some lifetime.

I'd be happy with 5 or 10.  365 seems unreasonable.

Is anybody keeping track of loose ends like this?


> We actually thought about pool applications when writing RFC 8915. The way to
> implement it is not very complicated: The pool administrator runs one or more
> NTS-KE servers. The NTS-KE servers have a shared key with each of the pool
> members and indicates which server the cookies are valid for using a NTPv4
> Server Negotiation NTS-KE record.

There are 2 issues with that approach.

The first is that the servers in the pool are not vetted.  There is nothing 
that keeps a bad guy from adding his servers to the pool.  NTS would guarantee 
that you got time from the intended server but not that the time was good.  I 
think we should avoid that false sense of security.

Second, there is no established protocol between NTS-KE servers and NTP 
servers.

NTPsec packages the KE server with ntpd so there is no need for that protocol. 
 I don't know of any split implementations.  So as a practical matter, it 
would be hard to put together a pool using that mechanism with available code.


Miroslav: What does chrony do?



-- 
These are my opinions.  I hate spam.