Re: [Ntp] Roughtime and Delay Attacks

Stewart Bryant <stewart.bryant@gmail.com> Tue, 09 April 2019 18:08 UTC

Return-Path: <stewart.bryant@gmail.com>
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 3AD3E1200FA for <ntp@ietfa.amsl.com>; Tue, 9 Apr 2019 11:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RE5F1ISUZkQO for <ntp@ietfa.amsl.com>; Tue, 9 Apr 2019 11:08:55 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4368A1200EF for <ntp@ietf.org>; Tue, 9 Apr 2019 11:08:55 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id y197so4440286wmd.0 for <ntp@ietf.org>; Tue, 09 Apr 2019 11:08:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=C15W//Du8xt9lk9/ZwNyx/ms2/lok3ntqTb8L4q/Mno=; b=tW5cTzm7xzKugv7YNJo8A+seLnOP0qnFl/EDxsPAjFS+aoMX3DHLTH0IMhC9cc5Vzy PYi6BS9uqmnLHcnizx2+F1p8YYglRXnJdpcd/6NNwTJ5B4yi2GvWdjfBWqXxH+lUpw/R jkvcj+alQRbQ2KgJHaJ8qLYLO7WtzRcJlD9yNOu+Y1JOE5cf+dO5XvDXYU8sCd6yzSFz kb5b1eVXwSe4anKES05kpdGMdVySOUecotglkIIdUHUBbFER+Jwy3GppPBZoShsxDEO+ f3NEz9FnQTqIbiy5FoLDPCaOYfsBt2nhC3d/BuJdG4mgtt6hUQHWdWVxbSIOLiM8gVuM SbQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=C15W//Du8xt9lk9/ZwNyx/ms2/lok3ntqTb8L4q/Mno=; b=SzP1O/yZaGMuwpMeli95oje5iwEweH+cCQd/hPhZNho+4Y4WCCP05HNLEHfOEPvZDp RDsv/Y06t641k74vmfivmnehwhS3MR/s/d5/+YmPFBcAz3lEMZysM1+uZ7LM/BX1UdYD zpqsml86D7z5FfsL7yr4z1Tq6vj/LCX15fNRB0jileWSk52Zz2g517TZkLkPJ9o+x3fZ WmlPcMXBBh7RJquxZSWfSQuO0IAESBN3wwCj4aPWk3z6iVgumyn8e+h67MPfMB6Re9Ds Rqf/CBcDWy9kizzfFe6FzJBVFfOVLbc9uVb7dRrMupDwksqMd2XBMKTlTiRogO6PfdWj g44Q==
X-Gm-Message-State: APjAAAWRrFB7Xg/bML6bpr30bULj8TdAeL8FaAZuiEnyz9pMAYB1TqsU RUZioFl5lBefl5PRhkalX5dw93/jQ6U=
X-Google-Smtp-Source: APXvYqzns8ZVhOyLNEh+OQE4fz1JkrwySGZCqeWSg2tvSHsuUVZ/I6x1gT8cETly3zvHw9fxB2Xhbg==
X-Received: by 2002:a1c:7611:: with SMTP id r17mr22137531wmc.98.1554833333368; Tue, 09 Apr 2019 11:08:53 -0700 (PDT)
Received: from [172.20.1.148] ([46.218.58.220]) by smtp.gmail.com with ESMTPSA id k9sm44494217wru.55.2019.04.09.11.08.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 11:08:52 -0700 (PDT)
To: Greg.Dowd@microchip.com, watson=40cloudflare.com@dmarc.ietf.org
Cc: 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: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <00d08b76-7ddc-1ee6-5e73-ea8f6f24971b@gmail.com>
Date: Tue, 9 Apr 2019 19:08:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; 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; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/KcTMomImA6thJElcdgvL6dvOh4c>
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, 09 Apr 2019 18:08:58 -0000

Right, that is all you know.

Rather than develop a whole new protocol couldn't we just carry SNTP 
over an encrypted channel and get the same benefit?

- Stewart


On 04/04/2019 20: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
>