[ntp:hackers] Time over HTTPS reference implementation
imp at bsdimp.com
Sun Dec 13 01:12:59 UTC 2015
On Sat, Dec 12, 2015 at 3:18 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>
> I have posted my reference implementation of "Time over HTTPS":
> I have also made a couple of changes to the specification:
> based on input from Asbjørn and Mark (Thanks!)
> Please help test and validate that this is a usable time
> transfer mechanism in the real network.
Here are some comments. They are mostly nits, and I have a
lot of this weird orange-green paint I like to splash on things.
1. "The client SHALL cache the fact that the server refuses time service
and SHALL NOT contact this server again."
Ever? For a day? A week? A month? Until someone tells it that things have
changed? Placing some limit on the cache, and how persistent the cache must
be seems prudent. What if I want time and I have little to no changeable
non-volatile storage available?
My knee jerk reaction is "SHALL cache for at least a week, where possible,
the fact..." and add "until its cache expires" at the end. But there may be
good reasons for another approach. Week may be too long for transient time
keeping issues, absent any way to know if a refusal to provide time right
now is due to an unwillingness, or just a lack of sync with a known source.
It may be too short to help mitigate when some knob violates the spec and
puts it into a router, though there's only so much that can be done to
firewall against that.
2. 8 iterations should get you to at best ~1ms. However, I believe that the
RTT (or is that RTT / 2) and the variance in RTT starts to dominate how
accurately you can get. Would it make sense to provide guidance on simple
algorithms to terminate early? How much noise does crypto add?
3. The HTTPS server could communicate it's confidence in its time by the
addition of a second, optional, field. This would be at least
ceil(log10(error)). If the server can query NTP, it can know very
precisely. If it can't (or does not wish to), it could return some
reasonable average (say -1, since any steered system can generally assume
it stays within 100ms). When it doesn't know, it could return 9 (which
would translate to approximately "I don't even know what decade this is").
However, this may be overkill. A good / bad flag seems simpler (and is
already present in the protocol). Though having something like '9' would
distinguish between "I'd like to provide time, but my watch is broken at
the moment" and "Time? **** off. get your own damn watch" which is hard in
the current protocol. It would also provide a good way for the client to
know when to give up. When -1 is reported, it makes little sense to drive
the error too far below 100ms.
More information about the hackers