Re: [Ntp] Roughtime and Delay Attacks
kristof.teichel@ptb.de Tue, 02 April 2019 07:33 UTC
Return-Path: <kristof.teichel@ptb.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A321201DB for <ntp@ietfa.amsl.com>; Tue, 2 Apr 2019 00:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYlgJF38OY4M for <ntp@ietfa.amsl.com>; Tue, 2 Apr 2019 00:33:03 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1274C1201CC for <ntp@ietf.org>; Tue, 2 Apr 2019 00:33:02 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id x327Wv01029548-x327Wv03029548 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=CAFAIL); Tue, 2 Apr 2019 09:32:57 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 8B9D97A1F9A; Tue, 2 Apr 2019 09:32:56 +0200 (CEST)
In-Reply-To: <CABUE3Xmg1vZedhEras54LC6WyChPhcZnqB2s1TNcMaoLbarkdQ@mail.gmail.com>
References: <CABUE3Xmg1vZedhEras54LC6WyChPhcZnqB2s1TNcMaoLbarkdQ@mail.gmail.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, ntp@ietf.org
Cc: Aanchal Malhotra <aanchal4@bu.edu>, Watson Ladd <watsonbladd@gmail.com>
MIME-Version: 1.0
Message-ID: <OFF21B3920.9A750F87-ONC12583D0.002454E6-C12583D0.00297785@ptb.de>
From: kristof.teichel@ptb.de
Date: Tue, 02 Apr 2019 09:33:14 +0200
Content-Type: multipart/alternative; boundary="=_alternative 00297783C12583D0_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/a68c82iHccnzjvf9R-GHlfUZ-q0>
Subject: Re: [Ntp] Roughtime and Delay Attacks
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 07:33:07 -0000
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
- [Ntp] Roughtime and Delay Attacks Tal Mizrahi
- Re: [Ntp] Roughtime and Delay Attacks kristof.teichel
- Re: [Ntp] Roughtime and Delay Attacks Tal Mizrahi
- Re: [Ntp] Roughtime and Delay Attacks Tony Finch
- Re: [Ntp] Roughtime and Delay Attacks kristof.teichel
- Re: [Ntp] Roughtime and Delay Attacks Hal Murray
- Re: [Ntp] Roughtime and Delay Attacks kristof.teichel
- Re: [Ntp] Roughtime and Delay Attacks Stewart Bryant
- Re: [Ntp] Roughtime and Delay Attacks Watson Ladd
- Re: [Ntp] Roughtime and Delay Attacks Greg.Dowd
- Re: [Ntp] Roughtime and Delay Attacks Joachim Fabini
- Re: [Ntp] Roughtime and Delay Attacks Stewart Bryant