What's left to doo on NTS

[Daniel Franke]

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 at ntpsec.org> wrote:
>
>
> rlaager at 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 at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel