For anyone interested in piggybacking one of the encrypted DNS efforts, there's a list of example use-cases being developed at: https://github.com/Encrypted-DNS-Deployment-Initiative/Use-Cases
And the initiative's site and information about participation is at https://www.encrypted-dns.org/ The chicken/egg problem of securely distributing information about DoH/DoT service endpoints is already called out. It's not a large leap to identify the need to leverage secure distribution of NTP source(s). Dan ----- On Mar 12, 2020, at 10:48 AM, Ask Bjørn Hansen [email protected] wrote: >> On Mar 12, 2020, at 09:45, Miroslav Lichvar <[email protected]> wrote: >> One of my suggestions was to specify a NTS-KE redirect where the >> server wouldn't provide cookies, but a TTL and a list of hostnames and >> addresses. It would basically be DNS over NTS-KE. Easy to implement on >> both servers and clients. If the clients were caching the results >> properly, the load should be a fraction of the NTS-KE load at the NTP >> servers. Would that make sense for pool.ntp.org? > > Isn’t that just partially re-implementing dns-over-http? For the secure > transfer > of “who’s in the pool” any of these would either solve or mitigate it: > > - dnssec > - clients doing doh to the pool dns servers > - clients only trusting a pool certificate authority (that only issues short > lived certs for x.nts.ntppool.org or some such). With this you don’t need > anything in dns and a mitm attacker at least need to be registered in the > pool. > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
