Re: [Ntp] Roughtime and Delay Attacks

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 <kristof.teichel@ptb.de> wrote:

> 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" <tal.mizrahi.phd@gmail.com>
> An:        "Aanchal Malhotra" <aanchal4@bu.edu>, "Watson Ladd" <
> watsonbladd@gmail.com>, kristof.teichel@ptb.de, ntp@ietf.org
> Datum:        02.04.2019 06:14
> Betreff:        [Ntp] Roughtime and Delay Attacks
> Gesendet von:        "ntp" <ntp-bounces@ietf.org>
> ------------------------------
>
>
>
> 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._______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>
>
>