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

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 1 Dec 2013 15:53:07 -0500

Hi, 

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

Comments please 

	Olafur

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
> Date: December 1, 2013 3:42:27 PM EST
> To: Olafur Gudmundsson <[email-masked]>
> 
> 
> A new version of I-D, draft-ogud-dhc-udp-time-option-01.txt
> has been successfully submitted by Olafur Gudmundsson and posted to the
> IETF repository.
> 
> Filename:	 draft-ogud-dhc-udp-time-option
> Revision:	 01
> Title:		 Providing Time over DHCP and ND for devices w/o reliable clock upon boot
> Creation date:	 2013-12-01
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-ogud-dhc-udp-time-option-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-ogud-dhc-udp-time-option
> Htmlized:        http://tools.ietf.org/html/draft-ogud-dhc-udp-time-option-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ogud-dhc-udp-time-option-01
> 
> Abstract:
>   Many small inexpensive computing devices like home routers, Rasberry
>   Pi etc. do not have a battery to allow clock chip to keep track of
>   time, thus the systems have no idea what the current time is upon
>   boot.  Number of modern services take Time Synchronization for
>   granted, but operating systems do not allow the start of these
>   services to be deferred until after accurate clock has been
>   confirmed.
> 
>   NTP provides accurate fine grain clock synchronization but in order
>   for NTP to succeed DNS needs to work.  DNSSEC resolvers will fail if
>   system clock is off by more than little bit.  This draft proposes a
>   mechanism to offer "reasonable" current time to devices upon boot via
>   DHCP, DHCPv6 and ND.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 16:18:09 -0500

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 1 Dec 2013 17:05:48 -0500

> 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 replaye…

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…

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…

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 17:29:14 -0500

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

Ah, thanks for explaining.   This is what I was missing—you're not doing this to avoid a threat at all, but rather to simply make DNSSEC work in a possibly non-secure mode until such time as you can bootstrap better time information.

This would be worth mentioning in the introduction and/or the security considerations section. You allude to it in the security considerations, but it's pretty oblique.

It is worth pointing out that NTP doesn't actually need DNS to work—DHCP can deliver NTP server addresses as IP addresses.   That said, this option seems to add value, since there is no guarantee that devices that implement the existing DHCP NTP will not send FQDNs rather than IP addresses.

---

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Dec 2013 19:31:11 -0500

On 12/1/2013 5:29 PM, Ted Lemon wrote:
>> 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.
> 
> Ah, thanks for explaining. This is what I was missing—you're not
> doing
this to avoid a threat at all, but rather to simply make DNSSEC work in
a possibly non-secure mode until such time as you can bootstrap better
time information.
> 
> This would be worth mentioning in the introduction and/or the
> security
considerations section. You allude to it in the security considerations,
but it's pretty oblique.
> 
> It is worth pointing out that NTP doesn't actually need DNS to
work—DHCP can deliver NTP server addresses as IP addresses. That said,
this option seems to add value, since there is no guarantee that devices
that implement the existing DHCP NTP will not send FQDNs rather than IP
addresses.

I had a long discussion with Bernie over the issue of delivering NTP IP
addresses via DHCP. We understand the issues you raised concerning
DNSSEC and have no disagreement about that. The problem is that for NTP
DNS names are preferred over IP addresses because that allows a server
maintainer to retire an NTP server. With an IP address there is no
chance that your local instance will know about this and continue to
bombard the old address. Moreover the newer pool option cannot be used
to any advantage.

When was the last time you looked at your NTP configuration and verified
that all of the servers listed are still valid? How often will DHCP
servers do this as a matter of course before providing such
provisioning? We have systems that are being bombarded by requests even
though no NTP server is responding to queries. We have plenty of
evidence of this. Even worse we have seen home routers which have
hard-coded IP addresses for NTP servers embedded. How long are those
going to be in operation?

I think we need to figure out how to get around the Catch-22 situation
of DNSSEC requiring relatively good time and NTP wanting to be able to
use DNS to find valid NTP servers.

We need a joint agreement on how to deal with this between DHCP and NTP
Working Groups assuming that is a viable option in the first place.
RFC5908 was not a good indication of this.

Danny

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 21:36:59 -0500

> RFC5908 was not a good indication of this.

RFC 5908 got approved pretty much accidentally, without finishing the review process in the DHC working group.   It was a major screwup, and I don't precisely know how it happened.   It doesn't really do what you wanted, and it certainly doesn't do what we wanted.   I agree that this needs to be resolved, but the resolution has to be based on reasoning, not an instinctive reaction to past pain.

I'm not even convinced that DHCP is the right way to distribute NTP server information.   I suspect Olafur may be thinking about the case that's more common at present, which is that an FQDN is hard-coded into the O.S. distribution, and resolved at startup time.   In that case, DHCP's ability to deliver NTP server IP addresses doesn't help.

As for the home router use model, it may be that what you really want is for the home router to query for an FQDN-only DHCP option from the ISP DHCP server, and then resolve that FQDN and respond to DHCP clients on the homenet with an IP address.   Since the FQDN is not hard-coded, and the IP address is (one hopes) resolved either at query time or when its TTL expires, this ought to prevent a repeat of the firmware burn-in incident.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 2 Dec 2013 08:20:33 -0500

> As for the home router use model, it may be that what you really want is for the home router to query for an FQDN-only DHCP option from the ISP DHCP server, and then resolve that FQDN and respond t…

Strictly speaking there is no difference between OS burned in NTP server name and DHCP server provided NTP server name, both 
require DNS resolution, root zone is signed, thus if the box wants to do DNSSEC validation as soon as it can, we end up with one of: 
	disable DNSSEC 
	false negative on validation 

repeat for any protocol that wants to open TLS or IPSEC connection before NTP completes. 
Giving out a NTP server address (as in IP address)  that is outside "local" net is not responsible behavior.

Right now for inexpensive boxes we have a choice of "real-bad" and "outstanding" time source, I'm advocating for something in the middle 
i.e. quick-and-close time for the devices that do not keep time when off. 

When been doing research on Open Recursive DNS Resolvers we keep finding more and more devices that answer all questions with 
answers that are basically current time either in binary, or text. This to me implies that there is hidden need for quick-and-dirty time. 

If you have not been following the changes in DNS, there is a push to move the resolution/validation to edge i.e. run resolver/validators on edge devices or even in applications as the "ISP" resolvers can not be counted on to do DNSSEC, and in many cases play games with answers. 

	Olafur

---

From: Sanjeev Gupta <[email-masked]>
Date: Mon, 2 Dec 2013 20:12:29 +0800

On Mon, Dec 2, 2013 at 8:31 AM, Danny Mayer <[email-masked]> wrote:

> The problem is that for NTP
> maintainer to retire an NTP server.
>

With the "server" directive, once the FQDN is resolved by the system
resolver, ntpd will continue with tah IP address, even if the FQDN changes,
till it is restarted.

We are talking only about time at startup, right?

Then, I do not see any issues if the DHCP server specifies a IP address; as
long as the server administrator can manage to check that the IP is valid
(for a short time in the future).

1. The DHCP server administrator SHOULD specify the IP address of a valid
NTP server.

or

2. DHCP Server software MUST resolve the NTP server name to an IP address
before providing it to clients

Or am I missing something even more basic?

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 3 Dec 2013 13:27:25 +0100

> use DNS to find valid NTP servers.

If the box doesn't have an rtc, and so maybe starts in 1970, and
doesn't have anything it can trust there is no way out of it.  You
first need _something_ you can trust be it time or some
certificate.

I do not trust my ISP, so I don't see how I can get that started
and be sure that both my time are correct and dnssec validates
properly.  The only way I see around this is that someone manually
checks that the time is correct.

Kurt