On 8/26/17, Hal Murray <hmur...@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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
