On 4/8/20 3:42 AM, Miroslav Lichvar wrote:
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.)
I'm not saying there is necessarily an issue, just a logical
inconsistency. If the DNS servers provided by DHCP are trusted, why
would any plain NTP servers also provided by DHCP not be trusted? I can
do nefarious things with either.
Generally speaking, on a network I admin, if I've configured DHCP to
provide things like NTP and DNS servers, it's because I intend client
devices to use those things. While some devices choose to ignore DHCP
provided DNS (and NTP), I can still reroute those requests at the edge
router. Is that also possible with NTS? Even if it gets rerouted to a
plain NTP server?
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.
That makes sense. But again, if I don't trust everything and everyone in
my network, why do I trust the provided DNS servers?
I feel like if this is on by default we're basically saying nobody
trusts any provided NTP server unless it supports NTS. If that's the
case, do away with the 'trusted network' verbiage and just say that only
NTS servers provided over DHCP will be used.
Additionally, what about the no-internet case? Will a local, non-NTS NTP
server be acceptable in that case? I feel like that would be handled by
the change to PEERNTP you mention above. But then can't attackers
"disable the synchronization" as you mention above, essentially forcing
us back to no additional security?
Maybe what we should really have is a REQUIRENTS option for chronyd?
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.
Does the alias provide no additional functionality? Does it help with an
estimate of running Fedora machines in the wild?
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.
Will there be some kind of 'canary domain' like there is for DoH
(use-application-dns.net)? Again from a network admin standpoint, if I
provide a local NTP server without NTS, I want an easy way to tell the
devices I manage to use it.
From a user standpoint, I like this change and the security it offers.
But with a network admin hat on, it feels like yet more local
infrastructure being pushed outside of my control.
_______________________________________________
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
