Blue-sky thread - ideas for well after 1.0

[Daniel Franke]

On 8/26/17, Hal Murray <hmurray at megapathdsl.net> wrote:

> Is there a good high-level writeup of NTS?

https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-09#section-1.2

> Why encrypt stuff?  (as compared to verify)

NTS authenticates everything and encrypts as much as possible without
breaking backward compatibility and middleboxes. Encryption is mostly
for privacy -- prevent leaking anything that could permit tracking of
mobile systems. Data minimization already solves 99% of this, but
since adding encryption is basically free, it should be the default
anytime there's not a particular reason you *want* middleboxes to be
able to snoop traffic.

> Are there any useful techniques for monitoring or debugging encrypted
> traffic?

Log encryption keys, or the plaintext itself, at endpoints. If you
don't have endpoint cooperation, then inability to extract debug info
is a feature, not a bug.

> 64 bits of days seems like way overkill.  32 bits of days is over 23 bits of
>
> years.  Are you really worried about more than a million years?

It certainly won't be *my* problem. But either way, packets, not bits,
are the bottleneck. NTP messages fit in one packet either way. The
extra 32 bits are free.

> Should the wire protocol use a non-leap time scale?  (and include the offset
>
> to UTC)

Either way, I favor including UTC-TAI offset as a field. But even
given that, providing timestamps as UTC rather than TAI gives more
information, since it enables conversion to calendar date & time
without needing a full leap table.

> That's the tip of an iceberg for getting POSIX to get their leap out of the
> sand.

Yeah, POSIX time sucks, but that's a separate problem. My proposal
allows NTP to do things the right way, while at same time translating
into POSIX with as much fidelity as it's capable of representing.