[mapreduce]

> 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.

[zokier]

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

[mikepurvis]

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.

[growse]

The don't really 'command' it, they 'suggest'. The client's free to ignore those suggestions :)

[Terr_]

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