Theo de Raadt <[email protected]> wrote: > > > Stuart Henderson <[email protected]> wrote: > > > On 2020-05-07, Marko Cupać <[email protected]> wrote: > > > Hi, > > > > > > why not change default constraint server in ntpd.conf from current > > > https://google.com to something more neutral / reputable? > > > > > > If https://www.openbsd.org does not want to be involved, perhaps > > > https://www.ntp.org would be fine. > > > > Neither of those are good options. One or a few servers, IPv4 only, > > only in North America, not peered with many ISPs, compared to a > > large geolocated server front-end, v4+v6, within a few network > > hops of much of the world, with people paid to keep it working, > > and ISPs will quickly notice if their connectivity is down. > > > > The other default constraints server listed (quad9, hosted on > > the very widely peered pch.net) is good for that too. > > > > What ntpd needs for a "constraints" server is a site that > > will a) stay online as much as possible and b) is likely > > enough to hand out something approximating the correct time, > > that's all. > > > > I'm not a big fan of using google.com for this on my own systems so > > I often just don't use it, but I can't argue that it's a bad choice > > overall, and I don't have an idea for another site that is both > > equally good and "more neutral". > > What it needs is someone who cannot afford to ever publish a > certificate for HEAD which is untrue. > > Noone satisfies that condition as well as Google.
I'd like to make a larger comment. We chose the constraint settings very carefully over years. The commit logs explain the justifications. Behind the scenes, we talked about it for hours. The recent addition of PCH servers for additional benefit in in pre-DNS (or even better pre-DNSSEC) conditions involved close to 100 emails, and that is is vaguely justified in the commit logs also. The default ntpd.conf is as functional and paranoid as we can make it. You've actually ignored the WORST part, which is access to pool.ntp.org -- there is less reason to trust that collection of people than the other TLS'd DNS service deliverers in the file! At best pool.ntp.org is secretively-selected un-authenticatable collectivism; they have even greater ability to filter truths and only deliver lies JUST TO YOU, compared to the https TLS constraints providers! Just about everything modern in our ntpd codebase and the ntpd.conf file ameliorates old-school NTP protocol weaknesses and the associated common delivery services. You distrust the google line, but google's tremendous difficulty at lying to you here protects you against the EASE with which pool.ntp.org could lie to you. You have judged the situation precisely backwards. But rather than going to the source, and seeing if there was previous discussion, there's this email thread on misc, which is so rarely a point of truth on anything. Awesome... /sarc
