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

[Olafur Gudmundsson <[e-mail]>]

On Dec 1, 2013, at 4:18 PM, Ted Lemon <[e-mail]> wrote:

> 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 "threat" the document is trying to address, device wants to DNSSEC or CERT validation but clock is far off thus VALID credentials fail validation. 
I can solve this for DNS by enabling DNSSEC after time is "reasonable", but then the next protocol comes along that needs this same thing …. 

The threat that this document "creates" is spoof of time thus old CERT's and DNSSEC records can be replayed, in order for that to succeed the
attacker needs to know what the device wants to do and the attacker can only do this on local link. 

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

If we take this to its logical conclusion why should anyone think it got a good address from the DHCP server? 
or a good DNS resolver? 

we are already making a leap-of-faith by accepting these how much worse is to accept "time" ? 

Well if I'm in random coffee shop yes then I would be concerned, but the router on the ISP connection at my home? 

For things to work right we have to create a hierarchy of time credentials inside the host 
at the bottom is 
	"clock close to Jan 1 1970"   ==> OK ask DHCP and/or ND for time 

Then: 
	"last saved time + X days < clock " ===> long time since last check what does DHCP say pick highest value 
	
	"clock is > last saved time" ==> we are ok see if NTP works 

At the top 
	"NTP radio and GPS time signal" ==> use this to set clock 


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

There is no need to spoof time to downgrade DNSSEC on local link, you need some device to answer w/o RRSIG records for all questions asked no matter where the questions go. ==> the document does not make things worse. 
Right now not being able to get time from local network is IDENTICAL to getting bad time from DHCP. 


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

Right,  but the draft does not make things any worse, if I want to spoof time, the easy way is to forge addresses for NTP servers to the ones I control, I do this by having the local (trusted) resolvers (supplied by untrustworthy DHCP) strip out all RRsig records, and I forge answers for all attempts trying to reach outside DNS servers/resolvers.  
Actually for clients that use the NTP DHCP option all I need to forge there are bad NTP server names. 

These attacks can only be conducted by someone that is on-path, and sees the DHCP messages. 

	Olafur