[ntp:hackers] A stop-gap authenticated time service
magnus at rubidium.dyndns.org
Tue Nov 10 01:11:23 UTC 2015
On 11/10/2015 12:29 AM, Poul-Henning Kamp wrote:
> In message <56411A3C.1000106 at rubidium.dyndns.org>, Magnus Danielson writes:
>>> I don't look into the RTT at all (for that and other reasons).
>>> What you can do is increase my uncertainty window.
>> If you create a slowly increasing asymmetric delay, very slow.
> It is trival to raise an alarm when a HTTPS request which should
> be sub second suddenly takes a minute.
Indeed, that's your RTT measurement right there.
The problem is really not with RTT, it's actually the only sane value
you can get. The trouble is that asymmetry and time error of nodes all
ends up in the time-error part of the equation and there is no safe way
of resolving them. When looking at TE and RTT together, you can draw
some conclusions, but it is not generally solveable.
For any protocol where you have signed time-stamps, and you assume you
can't tamper with the bits in the message, you can still play tricks
with the delay the messages experience. The time-of-flight in a
response, which is a form of RTT measure, you can measure, but from that
exchange itself it is hard to see where that delay went.
The take-away remains that you must be careful about how long the
packets is left out on the network before you consider them tampered.
As I said, it's good to have multiple methods, and this is one to
contribute, but there is limits to how much magic you get from any of them.
> In more general terms there is no way we can guarantee to know what
> time it is, but we can avoid yanking the clock around to bogus input
> and alert people that something shady is going on.
Indeed. Trust no method, discover their weaknesses and warn early, use
many sources and methods, that is the only way you can keep some
confidence. Precision however, well...
More information about the hackers