I know I’ve brought this up before, but I can’t remember exactly where.
It would be nice if DHCP could provide the current time as one of the pieces of information it provides with a lease. If you’re already trusting it for your IP address, you might as well trust it with the current UTC time: The current 64-bit timestamp would be enough to get timestamp-sensitive things working.
> If you’re already trusting it for your IP address, you might as well trust it with the current UTC time
I don't follow! How does trusting DHCP with IP address automatically mean I should trust it with the current UTC time?
Time requires higher degree of trust than IP.
I may not care what my IP address looks like but I might care a lot about what the current UTC time is and I might want this to come from a more trustworthy device.
You don't need to trust the dhcp time. But it would be useful for bootstrapping, especially devices without rtc. This does not really apply to your average PC which probably already has good guess on current time, those can simply just ignore the dhcp provided value.
The DHCP server provided value can not be much worse than 1970-01-01T00:00:00Z default value if you don't have any other data. And if you have some other data, e.g. ext4 superblock timestamps, you can pretty trivially protect against DHCP providing time from the past (i.e. use the maximum of different sources).
Finally, you can restrict the use of the dhcp provided time to the initial bootstrapping process only; it's not necessary to use it for system-wide clock
DHCP servers can command your dns config and hostname too. It's not a total mitm story since the certs are still on the machine itself but it's definitely more than just a local IP address.
To offer an example, if an attacker can manipulate the time then they can make the target accept expired or revoked cryptographic certificates, potentially enabling impersonation or man-in-the-middle attacks.
In contrast, a different IP than expected isn't such a big deal... Although it might break the collaboration of two computers as crude denial of service
> It would be nice if DHCP could provide the current time as one of the pieces of information it provides with a lease. [0]
DHCP can provide the IP address of one or more NTP servers to consult for time queries. I use this feature so that all of the machines on my LAN (at least the ones that can be configured to ask for and/or use this information) have the same general idea of what time it is.
I do that, with a local GSP-synced Pi. Very cheap and easy to set up with IPv4 at least.
That said, if you don't trust the DHCP server because some evil actor might give you the wrong time, why should you trust the NTP server it tells you about?
I agree that if you distrust the network operator (but must use the operated network for some reason) that you should accept as little configuration information provided by that operator as is reasonably possible.
That goes without saying.
I mentioned the fact that DHCP can provide NTP server information as a way to explain why DHCP wouldn't just straight-up provide "current time" information. Why do that when you can point people to a server running a far superior purpose-built timekeeping protocol? It'd just be silly to do the worse thing.
(Notice also that RFC2132 was published in 1997. In my mind, this moots any retorts that a good reason for providing time directly would be because the DHCP server's supplicant is too underpowered to run an NTP client. In 2024? On a consumer-grade device? No way.)
Oh yeah, certainly agree. Especially since devices can use SNTP[1] to talk to a NTP server if they just want to know the current time and don't need all the complexity of NTP.
I trust a free wifi hotspot to give me an IP (traffic will be protected by TLS), but not with the time. E. g. time from the past can be used to trick into accepting an expired TLS certificate. But for most wifi hotspots it will be unintentionally wrong because such devices often unmonitored and not maintained until they completely break.
If your DHCP server supports bulk queries (RFC6926: https://www.rfc-editor.org/rfc/rfc6926.html ) then responses to such a query from a dhcp client include a timestamp in the form of an 32-bit integer count of seconds since the epoch.
I don’t know how widely this DHCP RFC is supported though.
It would be nice if DHCP (or maybe wifi?) could provide the location as well, so that you could relay the airplane's geo position to the connected clients.
It would be nice if DHCP could provide the current time as one of the pieces of information it provides with a lease. If you’re already trusting it for your IP address, you might as well trust it with the current UTC time: The current 64-bit timestamp would be enough to get timestamp-sensitive things working.