Blue-sky thread - ideas for well after 1.0

[Eric S. Raymond]

Daniel Franke <dfoxfranke at gmail.com>:
> There aren't many deficiencies in NTPv4 which can't be fixed by adding
> extension fields.

True, and the basis of one of my proposal variants.

>                    A change big enough to make a version bump
> worthwhile would incorporate at least most of the following:
> 
> 1. Drop everything other than client/server mode. Replace mode 6 with
> something that runs over HTTPS on the NTS-KE port.
> 
> 2. Let client and server packets be formatted differently. Achieve
> data minimization by just taking the unnecessary fields out of client
> packets altogether.
> 
> 3. Forbid use of the legacy MAC field, thus fixing the hairiness
> around extension parsing.
> 
> 4. Make NTS mandatory. In the NTPv5 packet format, the version, mode,
> NTS unique identifier, and (in client packets) NTS cookie come first
> in plaintext, then the whole rest of the packet is encrypted.
> 
> 7. Don't implement leap smearing in the wire protocol (servers should
> always report accurate, unsmeared time), but standardize a formula for
> translating NTP time into smeared UNIX time seen by other
> applications.

I concur with all of these.

> 5. Ditch the useless poll, stratum, refid, and reference timestamp
> fields. Given that all of the above are implemented, origin timestamp
> also becomes redundant (NTS takes the place of its anti-spoofing
> role).

Aren't we going to need some equivalent of refid for loop detection?
Otherwise I agree these seem dispensable.

> 6. Represent timestamps as days, seconds, and fractions so that the
> time can be represented unambiguously during leap seconds. Make the
> day field 64 bits wide so that its range comfortable exceeds the
> lifespan of the solar system.

There be dragons here.  This would disrupt the implementation a *whole lot*,
enough to make verification rather difficult.  I think a more practical plan
would combine the following: (1) Include the server's epoch date in the
packet (27 bytes in ISO8601, at least until after 9999CE), (2) include
the server's leap offset, and (3) *remove* leap-second correction from
timestamps so they're just seconds from epoch.

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.