[ntp:hackers] Time over HTTPS reference implementation
phk at phk.freebsd.dk
Sun Dec 13 09:56:34 UTC 2015
In message <CANCZdfpUNBtv865T=cLLFpwRgAzsfeeyYG-sH+k0u7Rihm74aw at mail.gmail.com>
, Warner Losh writes:
>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?
The servers have no defense, if you do a "GET /" and set your U-A
to look like a browser, the server will have to hand you a Date:
header because you look like a legitimate user.
It will only take one single IoS vendor shipping something idiotic
to bring down normal HTTPS servers with this spec.
Even a poll to find out that the server (still) wont give you a
timestamp has significant cost.
I really do belive "No means NO!" semantics are appropriate.
>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?
With enough polls and an ability to precisely control your packet
transmission time, there is no theoretical limit.
In practice, getting below RTT (I'm not assuming symmetry) requires
really good luck and a LOT of iterations.
I put the limit at 8 because beyond that point I have yet to see
any improvement with my reference implementation.
>3. The HTTPS server could communicate it's confidence in its time by the
>addition of a second, optional, field.
Yes, and a third leap-second field and ...
But I really don't want to go down that road.
I only want this to be a stop-gap measure, to make NTP attacks
pointless until NTS or something else comes around.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the hackers