[LEAPSECS] stale leap second information

[Warner Losh]

> On Jan 16, 2015, at 3:37 AM, Tony Finch <dot at dotat.at> wrote:
> 
> $ dig +short leapsecond.dotat.at aaaa | sed 's/:6:/:06:/' | sort
> 1972:06:30::23:59:60
> ….
> 2012:06:30::23:59:60
> 2015:06:30::23:59:60

I’m *loving* this.

I think this would make the problem of “these damn NTP servers are lying to me, or
some of them are, who do I believe” when some NTP servers light up the leap second
bit and others don’t. Servers can use it to cross check the data the reference clocks are
giving them. Clients can use them to sort out source of truth to determine the truthiness
of a given NTP servers information.

It will also allow you to leverage DNSSEC to get all the security inherent in that. Oh wait :)
Or you could sign the data with a public key that BIPM could publish so the data can
be validated as authentic, though that only works if there’s a convention for getting
the signature for some canonical representation of the data.

Also like the convention of :58 to publish the last second of the month. While not strictly
a leap second, this tells the time code the exceptions to the length of month in the current
UTC timeline. In fact, you could actually make the lookups easier if you leveraged the domain
system. <month>.<year>.lastsec.utc.int would be the lookup. Wildcard entry for 23:59:59 would be
present. positive leap seconds would get a 23:59:60 entry, negative ones would get a 23:59:58
entry. This data format is compact and could have extremely long TTLs so it could be cached
very efficiently locally. Bad thing about compact data, though, is that it is much harder to sign
since there’d only be two different signatures making the spoofing problem an issue. DNSSEC
could solve that issue.

This could also be trivially extended to DUT1 where monthly, or even daily, DUT1 measurements
could be published by looking up increasingly specific numbers. <hour>.<day>.<month>.<year>.dut1.utc.int
and you look up the precision you need, with a generic current.dut1.utc.int for the latest estimate.
This would also give people a transition method off of UTC in the future should that become
necessary for people that need to know earth orientation. People building earth orienting
instruments today could use this data stream, plus UTC with the explicit expectation that |DUT1|
might exceed 1s and this data can be used to compensate. Given the long lead times involved,
though, I don’t imagine this would happen on a scale measured in anything less than decades :(.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150116/0e52eeb6/attachment.pgp>