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.
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. On Mon, Mar 4, 2019 at 3:58 PM Hal Murray via devel <devel@ntpsec.org> wrote: > > > rlaa...@wiktel.com said: > > CNAMEs don't really help. Certificate validation uses the original name > > anyway. > > I was assuming we could intercept the CNAME and use that for certificate > validation. Maybe I should have said SRV or TXT or ??? > > The normal getaddrinfo and friends automatically follow CNAMEs. Thus my > comment about needing some DNS code. > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
