> 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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
