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

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 00:13:17 -0500

On Dec 1, 2013, at 11:47 PM, Hal Murray <[email-masked]> wrote:
> Does DNS using DNSSEC return a specific error code for time-invalid?  Or just 
> a generic didn't-work?

A response with a bad clock fails to validate, which is the same as no response.

> How close does the time have to be for DNSSEC to work?

Closer than 1970.

> Could this problem be solved by setting up a bank of NTP servers at well 
> known IP Addresses?  Say, one next to each root DNS server.  If you tried to 
> do that, I'd expect a serious problem would be overload because idiots would 
> try to use them for normal NTP use rather than just getting off the ground.  
> It might be possible to discourage that by making them return crappy time.

History suggests otherwise.   If an IP address is hardcoded, it will get pummeled by devices that are too dumb to give up.

> Most ISPs already provide DNS servers for their customers.  How do their IP 
> address get setup in home routers?  Could NTP servers piggyback on that 
> mechanism if ISPs also provided NTP servers?

You mean DHCP?   Yes, that's what we're talking about.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 02 Dec 2013 00:27:13 -0500

> How close does the time have to be for DNSSEC to work?

That's a question that should be asked in the dnsext WG mailing list
(though technically the Working Group is now closed). Olafur and I
(apart from Ted who is IETF area director) are probably the only ones on
these lists who participate in that mailing list. Olafur was one of the
cochairs of the DNS ext working group.

The document does not describe the DNSSEC requirements for accurate time
and probably should so that it can be assessed in that light.
The ones I know about are RRSIG inception time and expiration time and
then there are certificate expiration date-times.

The proposal seems to suggest that a timestamp in 64-bit time_t be
distributed by DHCP. I'm not sure why not a NTP timestamp instead.
However most systems running a DNS server is likely to have a static
address in the first place and that is what DHCP distributes as
nameservers to query. Since they use static addresses do they
participate in DHCP services at all? And who says that the DHCP server
itself has accurate time?

> It might be possible to discourage that by making them return crappy time.

No, it would just overwhelm them. See the NIST time servers for an
example of heavy load.

> 
> [email-masked] said:
>> 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. 
> 

I wish they would provide NTP services in the same way. Unfortunately
although most ISP's will have NTP servers they do not usually tell their
customers about them and they certainly do not provide authenticated
packets like autokey.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 02 Dec 2013 05:37:27 +0000

We already know we want to discuss how long NTP will use an IP it got
from a DNS lookup.

We know there is no good API to get the TTL from this lookup.

An IP can easily be moved to another machine; there's no reason to have
a TTL for these.

On the other hand, there is a way to update ntpd's config file.

See http://support.ntp.org/Dev/GettingNtpdItsConfiguration for more
information, and we might want to look at "refreshing" URL-based
configurations on a schedule.

H

---

From: Warner Losh <[email-masked]>
Date: Sun, 1 Dec 2013 23:44:14 -0700

>> How close does the time have to be for DNSSEC to work?

So 5 years in the future is no problem?

Warner

---

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

> Does DNS using DNSSEC return a specific error code for time-invalid?  Or just 

RCODE==SERVFAIL, 

> How close does the time have to be for DNSSEC to work?

somewhere between a month and an hour depending on what device is looking up
for X.509 this might be somewhere between a year and a minute 
it all depends on how close to the edge the providers of Validatable Signatures still keep using them. 

> It might be possible to discourage that by making them return crappy time.

IFF there were enough NTP servers on a any cast addresss that might work most of the time. 
The draft is proposing to do this via naturally distributed solution the local DHCP server or router for ND, thus eliminating the need
for any additional infrastructure, this is based on the assumption that these "servers" have decent idea what the current time is. 

The problem in nutshell is that devices have to use their own time source or a distant one. 
To me it seems having a local (i.e. on local network but off device) is a reasonable starting point to get to the great distant one. 

> mechanism if ISPs also provided NTP servers?

DHCP NAMESERVER option returns the IP address of the DNS resolvers, 

	Olafur

---

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

> itself has accurate time?

Danny, Thanks for the kind introduction 

The reason for time_t is the dhcp-client can feed that directly into following call:
	 settimeofday(const struct timeval *tp, const struct timezone *tzp)

If there is better construct I wold be happy to update the draft with that. 

Be careful when you say "most systems running a DNS server" 
are you talking about resolver or authoritative server.  

In the second case you are right they are static and frequently well provisioned with good bandwidth, and 
at boot time the system has good idea why the current time is, but for all practical purposes unless they are signing
on the fly they do not need accurate time. 

ON THE OTHER HAND, resolvers and X.509 certificate checking is distributed and can take 
place on any device. As I said in another message DNS resolution is being pushed to the edge 
as devices that migrate between networks cannot count on the "local resolvers" to be "DNSSEC ready" 

You are right we can not count on the DHCP server to have good time, thus any DHCP server answering 
with the proposed option would need to make sure it has "decent current time", that is the reason I say in the
draft that the time should be within 10 minutes. 
When playing with cheap home routers I discovered that the devices can easily drift an hour a day, if NTP is not
invoked regularly, most of these devices just use 'ntpdate' and frequently run it from startup script once. 

> customers about them and they certainly do not provide authenticated

Will a hotel network provide NTP server, and would you trust it? 
Will a coffee shop provide NTP server ??? 

	Olafur

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Dec 2013 09:29:55 -0500

>> Does DNS using DNSSEC return a specific error code for time-invalid?
    >> Or just a generic didn't-work?
    >> 

Sadly, DNSEXT did not (despite repeatedly trying to socialize this idea a
decade ago) give anything other than SERVERR when things fail.  That isn't to
say that it can be done, but there is no standard way to do this.

Time SHOULD be within 1 hour, but in practice, records are signed with
30-day periods, so as long as you aren't in error across that boundary, 
you could be 12 or even 24 hours off.  

Having your time in the past (trying to validate things in the future) is
likely the more common case -- it's also likely the less vulnerable
situation, as if someone is going to replay old data, they are likely going
to replay it from the real past, not, the future :-)

Many suggest to turn off time validation when a CPE router boots up until it
can validate enough DNS to get time records --- if one runs the DNSSEC for
the NTP server well, then the records will validate for years at a time.
If the CPE touches a file after getting valid time after booting, then the
CPE won't be back in 1970, it will know the time is at least as recent as
when it last validated time via DNSSEC-secured NTP.

Danny Mayer <[email-masked]> wrote:
    > (apart from Ted who is IETF area director) are probably the only ones
    > on these lists who participate in that mailing list. Olafur was one of
    > the cochairs of the DNS ext working group.

I have done all of the above.

    > distributed by DHCP. I'm not sure why not a NTP timestamp instead.

I agree.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Dec 2013 09:30:50 -0500

> So 5 years in the future is no problem?

Under strict DNSSEC rules, 5 years in the future is the same as 5 years in
the past.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 09:38:12 -0500

> So 5 years in the future is no problem?

I was being mildly facetious, since this is a question that's pretty easy to answer, but difficult to answer precisely.   The answer depends on the zone configuration, but generally speaking "within days" is probably good enough.   See http://tools.ietf.org/html/rfc6781#section-4.4.2.2

---

From: Danny Mayer <[email-masked]>
Date: Mon, 02 Dec 2013 10:24:06 -0500

> are you talking about resolver or authoritative server.  

I actually mostly meant resolvers and authorative servers are really no
different in the sense being discussed here.

> as devices that migrate between networks cannot count on the "local resolvers" to be "DNSSEC ready" 
I doubt that the number of "local resolvers" used by the general
populace that can support DNSSEC reach even .1% today, never mind
whether the server has it enabled.

> Will a coffee shop provide NTP server ??? 

I would consider them no better than the ISP's. They only provide basic
services and almost certainly not NTP. But then how many applications
out there will demand DNSSEC authenticated information? Generally there
is no API to specify that from an application. When this gets into
browser software and banks give DNSSEC authenticated addresses then it
might take off.

Danny

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 2 Dec 2013 10:31:50 -0500

> whether the server has it enabled.

Chrome and Firefox have DNSSEC validation libraries in testing. 
Once they turn that on the numbers will jump. 
X.509 cert checks happen on edge devices today in large numbers. 
This is not just for DNSSEC this is for any device that wants to do time check before NTP can finish. 

> browser software and banks give DNSSEC authenticated addresses then it
See above, 

	Olafur

---

From: Warner Losh <[email-masked]>
Date: Mon, 2 Dec 2013 08:32:02 -0700

>> 	 settimeofday(const struct timeval *tp, const struct timezone *tzp)

During a leap second, the value of time_t is not well defined because by definition leap seconds don't happen in time_t/POSIX time scale (don't happen -- well don't consume space in the time_t timescale is more pedantically correct). Obscure point likely worth noting...  But using a NTP time stamp doesn't save you, since during a leap second its value is well defined, but the same as another second (ntp distinguishes in bits set in other parts of the header). Assuming the tolerance for this application is >> 1s, this won't matter, but might be worth specifying that during a leap second, the value returned shall be either the value of the prior second or the value of the next second to make it conform to most current usage.

Warner

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 12:12:48 -0500

On Dec 2, 2013, at 10:32 AM, Warner Losh <[email-masked]> wrote:
> Assuming the tolerance for this application is >> 1s, this won't matter, but might be worth specifying that during a leap second, the value returned shall be either the value of the prior second or the value of the next second to make it conform to most current usage.

I think the expectation is that the time will be updated with a more accurate mechanism later, and an error of 1s is not worth worrying about for typical devices, so this is almost certainly overkill.

---

From: Warner Losh <[email-masked]>
Date: Mon, 2 Dec 2013 11:12:57 -0700

> I think the expectation is that the time will be updated with a more accurate mechanism later, and an error of 1s is not worth worrying about for typical devices, so this is almost certainly overki…

This isn't to prevent an error of a second, but to bound the error to a second by adopting the main work arounds that are in practice today which do that.

Warner

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 02 Dec 2013 19:58:42 +0000

Warner Losh writes:
>>> The reason for time_t is the dhcp-client can feed that directly into
>>> following call: settimeofday(const struct timeval *tp, const struct
>>> timezone *tzp)
> 
> During a leap second, the value of time_t is not well defined because
> by definition leap seconds don't happen in time_t/POSIX time scale
> (don't happen -- well don't consume space in the time_t timescale is
> more pedantically correct). Obscure point likely worth noting...  But
> using a NTP time stamp doesn't save you, since during a leap second
> its value is well defined, but the same as another second (ntp
> distinguishes in bits set in other parts of the header). Assuming the
> tolerance for this application is >> 1s, this won't matter, but might
> be worth specifying that during a leap second, the value returned
> shall be either the value of the prior second or the value of the next
> second to make it conform to most current usage.

It's actually fuzzier than that, and this situation (which is handled
differently with ntpd under unix, ntpd under windows, and on systems
that "smear" the leap second over a longer period) is one of the cases
handled by the General Timestamp API project at Network Time Foundation,
described at http://nwtime.org/projects/timestamp-api/ .

H

---

From: Warner Losh <[email-masked]>
Date: Mon, 2 Dec 2013 13:09:06 -0700

> described at http://nwtime.org/projects/timestamp-api/ .

Actually, in all those cases it is within a second of the 'real' time, hence specifying that it should be one second or the other seems appropriate. The timestamp APIs are for sub-second resolution, while the time_t in this protocol has only a second resolution... The main point is that it should be (a) specified to be what's going to most likely happen (or keep bounds on the error)  and (b) something sane that doesn't introduce errors > tolerance of the protocol. Having it be completely unspecified is a mistake, since -1 could be returned...

Warner

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 02 Dec 2013 21:32:13 +0000

Warner Losh writes:
>> that "smear" the leap second over a longer period) is one of the
>> cases handled by the General Timestamp API project at Network Time
>> Foundation, described at http://nwtime.org/projects/timestamp-api/ .
> 
> Actually, in all those cases it is within a second of the 'real' time,
> hence specifying that it should be one second or the other seems
> appropriate. The timestamp APIs are for sub-second resolution, while the
> time_t in this protocol has only a second resolution... The main point
> is that it should be (a) specified to be what's going to most likely
> happen (or keep bounds on the error)  and (b) something sane that
> doesn't introduce errors > tolerance of the protocol. Having it be
> completely unspecified is a mistake, since -1 could be returned...

I'd suspect that usually 1 second will be the ballpark, but it's pretty
easy to find situations where the system clock is out by more than that.

I mention the General Timestamp API because that effort is looking at
use cases like this one from a larger persepective.

H

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Dec 2013 09:03:11 +1100

The inception and expiration times in RRSIGs is specified as seconds
since 00:00:00 Jan 1 1970 UTC excluding leap seconds modulo 2^32.

There are no recommended fudge factors to use when evaluating these
times though named sets the expire time to 3600 seconds in the past
by default when generating RRSIGs.  I believe the other signers do
similar.  I've considered making the inception timestamp a whole
day in the past to cope with badly set timezones.

The signature validity intervals are on the order of days.  Named
defaults to 30 days.  They are regenerated about a week before they
are due expire if not already regenerated due to zone content
changes.  The records should expire from caches before they become
invalid if re-signing is being done properly.

So if the validator and the signer are both within 30 minutes of
the true time validation should succeed.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Dec 2013 09:15:19 +1100

> times though named sets the expire time to 3600 seconds in the past

That should read "inception time to 3600 seconds in the past"

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2013 09:14:54 -0500

>> whether the server has it enabled.

    Olafur> Chrome and Firefox have DNSSEC validation libraries in testing. 
    Olafur> Once they turn that on the numbers will jump. 
    Olafur> X.509 cert checks happen on edge devices today in large numbers. 
    Olafur> This is not just for DNSSEC this is for any device that wants to
    Olafur> do time check before NTP can finish.  

X.509 checks happen "above" IP, closest to the application where one can ask
the user if they are sure.
DNSSEC checks happen "within" IP --- often on devices without users or
interfaces.

Home/CPE gateways will need to have a process to bootstrap to secure time,
and we will need to write this up in homenet, and if a DHCP option to provide
time to within an hour helps, GOOD.

---

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

> 	 settimeofday(const struct timeval *tp, const struct timezone *tzp)

I don't think that is something we want every dhcp client to do.
If ntpd is running you really don't want something else to change
the time.

Kurt

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 04 Dec 2013 01:40:17 +0000

> If ntpd is running you really don't want something else to change

There is a difference between DHCP at startup and a DHCP "refresh".

I suspect that a DHCP refresh should leave the clock alone.

For the startup case:

I think the best solution to this problem for LAN-connected devices will
turn out to be PTP.  And if that is not available, if you can't trust
your DHCP server to tell you what time it is, why would you trust it to
give you an IP address?

H