Subject: [Ntp] Roughtime and Delay Attacks

From: Tal Mizrahi <[email-masked]>
Date: Tue, 2 Apr 2019 07:13:42 +0300

Hi Aanchal, Watson, Kristof,

Thanks for a fruitful discussion in Prague.

To summarize our discussion regarding delay attacks: in order to roughly
detect delay attacks, a client has a MAX bound on the RTT. If the RTT of a
request-response handshake exceeds MAX, the client ignores the
corresponding server. Indeed, I believe this helps the client to roughly
detect delay attacks.

Question: in the scenario above, i.e., RTT>MAX, how can the client prove
the server's malfeasance? The cryptographic chain in this example would
indicate that all the servers are well, and the client has no way to prove
that RTT>MAX. What am I missing?

Thanks,
Tal.

---

From: [email-masked]
Date: Tue, 2 Apr 2019 09:33:14 +0200

Hi all,

I think it is essential that we get started on not only a threat analysis, 
but also a clear list of goals and (I believe roughtime is one of the few 
cases where this might make sense) non-goals.
Off the top of my head:
- Roughtime is supposed to do one thing very well: if a server is giving 
out visibly false time (with unconspicuously small RTT), then Roughtime 
can give cryptographic proof of this server's message not fitting into the 
time context of other servers' messages
- Absence of proof of malfeasance is not proof of absence of malfeasance! 
Roughtime should probably not be used as a witness that a server is 
overall "good" (at best that it has been good so far...).
- Roughtime (AFAIK) still needs to include some considerations of RTT in 
its analysis somehow (see below).

Towards that last point and also Tal's question:
A case distinction (perhaps better presented as a table) should be made 
for the relations between "good/bad" offset and "long/short" RTT:
* Good offset at short RTT: proof that (in this instance!!), the server 
behaved well and the association was not attacked
* Good offset at long RTT: could imply either good or bad server 
behavior... certainly an oddity, so potentially report-worthy?
* Bad offset at short RTT: strong proof of server malfeasance, absolutely 
report-worthy and actually the reason why Roughtime was built
* Bad offset at long RTT: no proof of server malfeasance in particular... 
but proof that something bad is going on, and IMO report-worthy

The crux here is that the distinction of "long/short" RTT actually depends 
on the offset.
That is why I'm not convinced that a simple threshold is the way to go for 
RTT handling.
Perhaps attaching the RTT or half the RTT to metadata for every offset 
measurement is better? 
As in: "this server's time messages yielded a measured offset of X with a 
possible error of Y"... and then evaluate this as an interval [X-Y, X+Y] 
and make your "good/bad" criteria also an interval?
Then the measurement interval can be contained in the criteria intervall 
(i.e. everything is good), can lie partly inside and partly outside of it 
(i.e. uncertain result) or they can be completely disjoint (i.e. proof of 
server malfeasance). 
This does cause a good amount of possibly unwanted complexity... but it 
would also be significantly more expressive!

Thanks for the helpful discussion and best regards,
Kristof

Von:    "Tal Mizrahi" <[email-masked]>
An:     "Aanchal Malhotra" <[email-masked]>, "Watson Ladd" 
<[email-masked]>, [email-masked], [email-masked]
Datum:  02.04.2019 06:14
Betreff:        [Ntp] Roughtime and Delay Attacks
Gesendet von:   "ntp" <[email-masked]>

Thanks,
Tal._______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 2 Apr 2019 10:53:19 +0300

Hi Kristof,

Thanks for the clarification.
Your description makes sense, and I believe this analysis MUST be in the
draft, preferably at the beginning of the draft.

Cheers,
Tal.

On Tue, Apr 2, 2019 at 10:33 AM <[email-masked]> wrote:

> out visibly false time (with unconspicuously small RTT), then Roughtime can
> give cryptographic proof of this server's message not fitting into the time
> context of other servers' messages
> Roughtime should probably not be used as a witness that a server is overall
> "good" (at best that it has been good so far...).
> An:        "Aanchal Malhotra" <[email-masked]>, "Watson Ladd" <
> [email-masked]>, [email-masked], [email-masked]
> Datum:        02.04.2019 06:14
> ------------------------------
>
>
>

---

From: Tony Finch <[email-masked]>
Date: Tue, 2 Apr 2019 16:26:53 +0100

> its analysis somehow (see below).

Maybe roughtime clients should use the Chronos clock selection algorithm,
because it is supposed to be resistant to delay attacks.

https://tools.ietf.org/html/draft-schiff-ntp-chronos-02

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Foreland to Selsey Bill: Westerly or southwesterly 5 or 6, becoming
variable 3 or 4. Slight, occasionally moderate at first. Rain or showers,
occasionally thundery. Good, occasionally moderate.

---

From: [email-masked]
Date: Wed, 3 Apr 2019 08:42:23 +0200

Hey Tony and everyone,

I believe this idea sadly cannot work, due to the difference contexts of 
how Chronos resists delay attacks versus how delay attacks potentially 
affect the workings of Roughtime.
Chronos mitigates delay attacks (and, actually, all kinds of attacks or 
malfeasance) by evaluating time signals from many sources and using this 
large collection of data to make smart estimations about the true time.
Roughtime deliberately looks at the associations to single server and 
tries to judge whether (and potentially prove that) each single given 
server is showing signs of malfeasance.
Their aims and scopes are so different (looking at the whole system to 
find the best estimation for a global truth versusbasically performing 
audits of singular parts of said system) - I just don't see how to combine 
or borrow techniques in the way you suggest.

Best regards,
Kristof

Von:    "Tony Finch" <[email-masked]>
An:     [email-masked]
Kopie:  "Tal Mizrahi" <[email-masked]>, [email-masked], "Aanchal 
Malhotra" <[email-masked]>, "Watson Ladd" <[email-masked]>
Datum:  02.04.2019 17:52
Betreff:        Re: [Ntp] Roughtime and Delay Attacks

Tony.