Blue-sky thread - ideas for well after 1.0
dfoxfranke at gmail.com
Sun Aug 27 02:46:28 UTC 2017
On 8/26/17, Hal Murray <hmurray at megapathdsl.net> wrote:
> Is there a good high-level writeup of NTS?
> 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
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
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.
More information about the devel