On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote: > It doesn't make much sense to me for this to default to on if we still > "trust" the DNS servers provided over DHCP. What is the issue with using untrusted DNS servers here? An NTS client is supposed to verify the certificates. Local MITM attackers shouldn't be able to force the client to synchronize to a different NTP server. (Of course, they can always disable the synchronization.) > Additionally, it's not clear to > me from the proposal what it would take for an NTP server provided over DHCP > to be "trusted", or what a "trusted network" is. Are only NTS-enabled > sources to be trusted? Generally, yes. What I meant, if someone for example had at home a stratum 1 server (e.g. synchronized to GPS) and they trusted everything and everyone in their local network, it would make sense to still use the server (without NTS) in addition to any external time servers authenticated by NTS. The question is if we need to change the default value of the PEERNTP option. There could be a new default which adds the servers provided by DHCP only if chronyd is not using any servers with enabled authentication. > What becomes of the old default fedora.pool.ntp.org? It would still work, even if we didn't use it by default. The name is just an alias for pool.ntp.org. The servers used in the current default configuration are not run by Fedora. > Finally, from a purely personal standpoint, I don't like seeing yet more > infrastructure being handed over to a hyperscaler like Cloudflare (see also > DoH in Firefox). I would be less opposed to this being default if > pool.ntp.org found a way to support it. Yes, that's a valid point, which we need to consider. I don't have a strong opinion either way. I'd like to see pool.ntp.org to support NTS. But I'm not sure if the trust of not being attacked will be comparable to a single entity running the servers, even if the pool has a sufficient number of NTS-enabled servers and implements some mitigations like mixing servers from different countries. -- Miroslav Lichvar _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
