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. > There is a different problem that might need to be addressed first. > MITM attackers could circumvent NTS simply by joining the pool. How > could that be prevented or minimized? Not accept any new members and > trust the old ones they won't do any harm? A year long waiting list > for NTS? Some variation of that, stricter monitoring and more active probing of pool servers. Itd be hard to mitigate a targeted attack. I have worked with some people who have probed IPv6 servers to see if any of them seemed to react (ala the shodan fiasco some time ago). The pool system could make sure to always offer clients diversity in which servers it tells a client to use (diversity by ASN, user who registered the server, etc) to make it hard for an attacker to control all the servers a client might use at any given time. Ask _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
