What's left to doo on NTS

[Hal Murray]

> The intended design for running NTS with pool servers is that only the pool
> operator runs an NTS-KE server. The NTS-KE server then picks an NTS-enabled
> NTP server out of the pool and serves you an appropriate NTPv4 Server
> Negotiation Record. Individual server operators, on a one-time basis,
> establish a shared secret with the pool operator out-of-band; this secret is
> used as the master key for creating and decrypting cookies. As recommended in
> the draft RFC, this key can be rotated on a periodic basis using a
> key-derivation function such as HKDF as a ratchet. Since new keys are
> deterministically derived from old ones (using a one-way function so you
> can't go backward), no communication is required as long as the pool operator
> and server operator agree on a schedule for generating new keys and
> forgetting old ones. They don't have to synchronize this perfectly; as long
> as the pool operator isn't still issuing new cookies under a given key-ID
> when the server operator has already forgotten that ID, it'll work. 

Thanks.  I think that should be folded into the draft, probably a new top 
level section.  Maybe something like expected operations.

There is a constraint on the cookies.  The pool operator can't get ahead of 
the NTP servers.  I'm thinking of a 5 minute delay.

Is the can't go backwards significant?


> In any case, you should absolutely not pay attention to anything you get from
> DNS when validating a certificate. Whatever name the users puts in the
> configuration file is what you should expect to see in the certificate. 

Thanks again.  That seems obvious now.  I'm not sure why I went down the wrong 
path last night.  It's probably worth adding to the draft and/or explaining 
why not to to anything fancy with DNS.



-- 
These are my opinions.  I hate spam.