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