[ntp:hackers] A stop-gap authenticated time service

Magnus Danielson 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 mailing list