Re: [dhcwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt

[Ted Lemon <[e-mail]>]

On Dec 1, 2013, at 3:53 PM, Olafur Gudmundsson <[e-mail]> wrote:
> I wrote up this short document in order to address a problem seen in certain devices
> that do not have good time at startup. The document  proposes a DHCv4 option and
> DHCPv6 option to supply current time to a device. (there is also a proposed ND option
> for the same thing). 
> 
> I looked into using option 152 from Bulk Query but that is only 32 bit long, and 
> it seems cleaner to just get a 64bit time_t option into DHC

I think it's worth thinking about the threat model this addresses, and the threats to which it exposes clients.   The threat model it addresses is the one where ancient DNSSEC responses are replayed in order to fool the client with stale information that would fail to validate (right?).

The problem is that the trust model for DHCP doesn't provide any assurance that the time being provided by DHCP will be any more trustworthy, even if the DHCP message is authenticated using the new proposal for doing public-key authentication of DHCP messages.  This authentication model typically depends on a leap of faith or else a pre-shared public key.   In the latter case, the time could be considered reasonably trustworthy.   In the former case, there's no reason at all to consider it trustworthy—if the DNS server on the network is going to attack you, so is the DHCP server.

Hm, okay.   The one thing I can see this protecting against is the case of a rogue DNS server attempting to slam responses at a client on an otherwise-trustworthy wire.   But this is a really hard attack—it has to have stored an old signed DNS hierarchy with stale keys that have been compromised.   This seems like it would be a fairly difficult achievement—to present a consistent out-of-date hierarchy, the rogue server would have to have or get answers to any conceivable query that could be made against it, and be able to produce them faster than the real DNS server.   Even if it has a copy of an old root key, this is a tall order, and furthermore depends on the client resolver not having a more recent root key, which could be used to disprove the attacker's assertion that an old key is current.   It seems like SAVI would be a better way to prevent this attack.

What am I missing here?

(None of this is to say that a time option is necessarily a bad idea—I'm just not convinced that it addresses a plausible threat model.)