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

Greg Dowd Greg.Dowd at microsemi.com
Tue Nov 10 16:38:08 UTC 2015


You are definitely correct that many applications can accept a second or two of movement per poll but I think looking towards the future the bar is being set much lower than that.  Large sections of the Internet show timing stability in the 100s of microseconds and asymmetries in the sub 100 millisecond range.  Of course, frustratingly, it won't stay that way so it's hard to maintain tight sync over time but we can surely do better than a 1-2s per poll.

But, you are correct that the time error estimate can always be bounded by the RTT.  So clock accuracy will likely be better.  Or so we thought when we were working on the secure timing protocols back in the early 2000s.  So, like the TAACCS and NTF TimestampAPI projects, it may be sufficient to implement any layered approach with the understanding that it exists to protect the underlying time transport, hopefully without degrading it, and bounding the error estimates using alternate methods.


-----Original Message-----
From: hackers [mailto:hackers-bounces+greg.dowd=microsemi.com at lists.ntp.org] On Behalf Of Poul-Henning Kamp
Sent: Tuesday, November 10, 2015 2:20 AM
To: Miroslav Lichvar
Cc: hackers at lists.ntp.org; magnus at rubidium.se
Subject: Re: [ntp:hackers] A stop-gap authenticated time service

EXTERNAL EMAIL


--------
In message <20151110100916.GS11550 at localhost>, Miroslav Lichvar writes:
>On Tue, Nov 10, 2015 at 07:58:05AM +0000, Poul-Henning Kamp wrote:
>> The only variable left for the attacker to tamper with is the RTT 
>> which I can reliably measure and thus detect said tampering.
>
>I don't think delay added in a MITM attack can be realiably detected.
>The attacker can increase the delay by a small amount and slowly, so it 
>looks like the network is getting congested or the HTTPS server is 
>overloaded and it needs more time to respond.

Right, and how much can he shift my time that way ?   He can shift it
at most the increased RTT.

So far I have yet to see a HTTPS server that didn't respond in at most one second on an already established connection, and that was a pretty pathological choice of HTTPS server, seen from Denmark.

So at best, he can shift my time a second or maybe two.

That's good enough for a LOT of purposes.

>Sure, the admin could set a very tight limit on the delay, but then it 
>will drop measurements when the network really is congested or the 
>server is overloaded.

Unlikely, see above.

>I think that depends on what error is acceptable.

Of course it does!

But there is a very big difference between "Drive-by attacker can shift your clock *anywhere he wants* and "determined attack can shift it a second or two before you notice".

--
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.
_______________________________________________
hackers mailing list
hackers at lists.ntp.org
http://lists.ntp.org/listinfo/hackers


More information about the hackers mailing list