IETF Logo Mail Archive

Re: [Ntp] Roughtime and Delay Attacks

Joachim Fabini <Joachim.Fabini@tuwien.ac.at> Thu, 04 April 2019 21:16 UTC

Return-Path: <Joachim.Fabini@tuwien.ac.at>
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 454F1120188 for <ntp@ietfa.amsl.com>; Thu, 4 Apr 2019 14:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qNR8xo6vGKJI for <ntp@ietfa.amsl.com>; Thu, 4 Apr 2019 14:15:58 -0700 (PDT)
Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795311204C3 for <ntp@ietf.org>; Thu, 4 Apr 2019 14:15:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id 52E0F630E9E3; Thu, 4 Apr 2019 23:15:52 +0200 (CEST)
Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoHqoYGivMCQ; Thu, 4 Apr 2019 23:15:50 +0200 (CEST)
Received: from [10.0.0.27] (193-154-91-189.adsl.highway.telekom.at [193.154.91.189]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id 38DCE630E9D7; Thu, 4 Apr 2019 23:15:50 +0200 (CEST)
To: ntp@ietf.org
References: <20190403072255.EA16E40605C@ip-64-139-1-69.sjc.megapath.net> <OF1EB096AA.8F10FC47-ONC12583D1.002B338D-C12583D1.002C46D5@ptb.de> <47b2705b-e29b-320b-c832-3d6c4e7feeb9@gmail.com> <CAN2QdAFgamnmehCodorszjM-=kt7QCd0ThFcACUu5CjpqP-stg@mail.gmail.com> <BYAPR11MB32395EE9ABA1A9F283F1A3FAFC500@BYAPR11MB3239.namprd11.prod.outlook.com>
From: Joachim Fabini <Joachim.Fabini@tuwien.ac.at>
Openpgp: preference=signencrypt
Autocrypt: addr=Joachim.Fabini@tuwien.ac.at; prefer-encrypt=mutual; keydata= mQENBFN/ZBIBCADMmi08FdbN6Gcq8fr/HFOT0Rhlfez5bpWc0vppC2NF186TDM07H9r85MSy 3JKk2ghUimSB4nRj2FZgA9KdKCgr4nVLdRpMGAvfEp5q9CNpC3Oc3KEs0tknbOZjPrzK9aI1 G1gLvyFxxluCvbxtp0b8oG9HC5gNLeTXTH4KvdVXGu9fjsw+PP2/Sx0Fvk8BR3vGZ/56J/EL qer55TK436pc6br1VW/KzwFgWFDGBIUXEGY8n2Iic+ASp5CVyYdsHi8XLB00fizttWE224Ch mAMolFw0kr4ykT3bzKVoFp4V6noqL1L1E6W+yY8YgkjU7YL0WSKAm0hoyGwxDYSVr0wdABEB AAG0LEpvYWNoaW0gRmFiaW5pIDxKb2FjaGltLkZhYmluaUB0dXdpZW4uYWMuYXQ+iQE/BBMB AgApBQJTf2QSAhsjBQkJZgGABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQoI/cE+9G p9KsmwgAxyTqWyYcpErMFZUmMc4fZmZJGbCOXInfpdhGgB1qCjlcuamzM1Q9s7IGQxzGTW4J YOV689DN/Bg2sWRL6Wy1qutKL5lcUhu4r8hxWlFBqHLf9QLDOwEfk7PE8oX8ARtzCh6Pvc6I Y9OxyMN7FbIUcJnRIrljmG78ve1fGz8kxbw/jPkkSZJOvsTgMVQYpZMAwP9NjLDJjIRs09ov hWpgXkolqQQDLRWRVsRB41zwRAZyr85g7chxOD1BWxf3eV/9nEyvZN2cMAd4Hz7PNUpgsuF2 5KXPE0J/l+EVWQMAo62kBS9TgC+ikjEetCxwIKhnU208nfOrTDl4etoN0rzE67kBDQRTf2QS AQgA3jZtzwyjaoMRyd02Qy881r8AjXTZrQlGKmfzEMuFIfkkor3Rui0jP6Cr1GgI4Pa2nDSg 0/V1R0TOoFiEjaxXjxKBo6jRoqGXD929zlNM07ueupfdR1mKoN6Hr+1AalmIf9POOqc7DpVn K+YWiM45gbfoAxA/C09vZQX4u1SYrQZEemOT/Z1KpFI3dICKfzuaVw83CVnmNSEqSegWetP6 2ksYgwFYN7UuRr8NEpckMvzn5HrkYs2TE+TMpcaB3JDC3dklADfJvytJNyAGqb3G2BeBWgIv KXypZbyd/4Qw6hTjNYy/WpgUCPPsMtzSatjEgowmHjZbdLOR7FjNXkY6KwARAQABiQElBBgB AgAPBQJTf2QSAhsMBQkJZgGAAAoJEKCP3BPvRqfS91QIALqzvaTpEefODaiKfVeCv4dwxZGB VhHzDiXrDGZCGJd982pasZeZnJbQT/bmt0HSyTKgBjwpxzV5FBKT7WRRmuLqdul/2n1wAcxk b0t7FewpOmOIi5sEFuOVx6jbY7dzpiOyAnaaXsYt76ydHmWUxe22ii2QI9hI7PxGvTxHIa8K N+vt89bkW7eXmQfEDpRjjhM4nXjmNUYtefmgwnX3L6geXP/R5bf1ELDRllOR2+cjz47kZbCR E/5O5v1evN1QlA+wxnikwRyrTyXzKl3w88rNsSEZYDokDGyWdLGtgVuyjkYX1XhBGKq0DfYK uTh5FsArNOX7/MdKWYjVXlwf5Fo=
Message-ID: <5f4f8c3f-e9b3-e3c8-bdfc-784d9159ae98@tuwien.ac.at>
Date: Thu, 04 Apr 2019 23:15:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <BYAPR11MB32395EE9ABA1A9F283F1A3FAFC500@BYAPR11MB3239.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/8_RrrH6qqlh-YtMLpMmzAA--RLE>
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: Thu, 04 Apr 2019 21:16:02 -0000

As a side note: the paper on delay attacks and possible constraints that
triggered this discussion is currently under review for a journal. Its
pre-print can be downloaded from arxiv.org
(https://arxiv.org/abs/1811.08569 ) and may support in identifying
challenges and solutions in guaranteed clock synchronization accuracy.

Joachim

On 04.04.2019 21:16, Greg.Dowd@microchip.com wrote:
> Actually, T ~ Ts - RTT.  Asymmetry could be up to 99+% in malicious or broken environment.
> 
> 
> Greg Dowd
> Principal Engineering Technologist, FTD
> Microsemi 
> 3870 N. First St. | San Jose | CA 95134 | USA
> Office: 408.964.7643
> Email: greg.dowd@microchip.com
> Company Website:  www.microsemi.com
> 
> 
> 
> -----Original Message-----
> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Watson Ladd
> Sent: Thursday, April 4, 2019 9:55 AM
> To: Stewart Bryant <stewart.bryant@gmail.com>
> Cc: ntp@ietf.org
> Subject: Re: [Ntp] Roughtime and Delay Attacks
> 
> External E-Mail
> 
> 
> On Thu, Apr 4, 2019 at 2:00 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
>>
>> Sorry I am struggling to understand how the protection works.
>>
>> If C (who has just woken) sends a request to S, then all C knows is 
>> that T ~ Ts - 1/2 RTT. C can know that it was S that replied, but C 
>> cannot possibly know if S was lying or if an on-path router delayed the packet.
> 
> Correct.
> 
>>
>> C can keep asking S, and within the limits of the server delay and the 
>> variation in the routing path and queuing delays RTT stay sort of 
>> constant, so C can be suspicious if it changes after it has been 
>> running or if Ts - 1/2 RTT changes by more than the known drift in its 
>> local clock. However routing paths do change and there are traffic 
>> congestion delays in networks.
>>
>> C can ask S', S'' etc and build up a picture of various servers time, 
>> but it has to be careful that the paths are disjoint and that S, S' 
>> and S'' have truly independent and authoritative master clocks.
>>
>> On the other hand, if the routers are compromised, then there are much 
>> worse things that can do, so we normally assume that they are truthful.
>>
>> So how does this design do better than "T ~ Ts - 1/2 RTT assuming S 
>> did not lie and also was not simply wrong"?
> 
> It doesn't. But this is fine. RTTs can be seconds, not hours.
> 
>>
>> - Stewart
>>
>>
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>

v2.23.0 | Report a Bug | By Email