Re: [Ntp] I-D Action: draft-roughtime-aanchal-02.txt

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Wed, 29 May 2019 13:29 UTC

Return-Path: <tal.mizrahi.phd@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 C3A6812012C; Wed, 29 May 2019 06:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 qUr3ALfeCKK1; Wed, 29 May 2019 06:29:09 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 9AA0012011D; Wed, 29 May 2019 06:29:09 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id l3so2522103qtj.5; Wed, 29 May 2019 06:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LsFJmY12k64ov45Eb/9TKhzKBIIay+EpET0oJ47brvw=; b=oa7ivGSHGjEyNoVsBfffi2P07CymgEFlibQO5VCYgZreHSlrx/ydMzn1lcdTxP83Dy gwPZY3I0y0jlud5yip5MO/lfiYzHPdAxsts00+RffegFk12awakbklAJx4sMfMNEtYwP Ar0bwcv9E2i8FEIm5LP0+tUPNDuyz4w8m1xBSmLd309LA6gFrkH4b8bCytnQBavZJnDW iorKuouPUjdb7sct8Dl5NLKnEJk1YQU6nglwMqRAs6h0UczGSsSC4rC0ywMVUjcmxlYc U8jXTMkN7UWjX4KCXa4U3nQ4tJ2pgExO99eHEp9wUKcaDuRGYU6inIa/A/q5uGjRIGpW 8Byw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LsFJmY12k64ov45Eb/9TKhzKBIIay+EpET0oJ47brvw=; b=Sx/XSC3KuBcgLvhlFXwfkczFighSwcQ7x4wBlQoIga1JweQmewqNfkG3RmzDaHz0Iw otJJO78SNvBxX9E5oJZ5vSMmzDMx3n3x703WxU8OlzhURlLSjb23tEHwFegnk3TO+e4m +Jo8hoDzfZkRofbPI5LlMqiDFyCMxrBbfibVjvl6gCgFkPUOO9dsYugk+s/IS3N330MZ QV6oGLqxvx3RzIgWa7zfj8OK54QBKFohcucKe5+Wlk8QYpkn8PSPOyipspFMCyaVXS/o LwGW/ee5qdkInB3kCNDWPrrd9H3239jrMsqkcspTZxt1qdocVPqBAQMc0cgEVgoW/NUl XBJQ==
X-Gm-Message-State: APjAAAXHnoMXXjJ0s2tSj1E8reZW4Zs0aF6msg7OQR31V9SLps0/grVb ceWiNUNY29xlNTQ5jTAvsvC0eZk2hHBBJeGlhf1dY7WPA+8=
X-Google-Smtp-Source: APXvYqxYgV8MnnWz5ST66YsiqGU1+/SkFfhnZHkcAWqviJLpDJvePq20ttKWG55G79/jFobnUYOKIk0BZ8L+GGlSFQk=
X-Received: by 2002:a0c:b929:: with SMTP id u41mr40184722qvf.50.1559136543530; Wed, 29 May 2019 06:29:03 -0700 (PDT)
MIME-Version: 1.0
References: <155897662160.809.5527655773398720605@ietfa.amsl.com>
In-Reply-To: <155897662160.809.5527655773398720605@ietfa.amsl.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Wed, 29 May 2019 16:28:51 +0300
Message-ID: <CABUE3Xk60A+r5fgs7H7Srkyyn7yX8M0Fyw=jEi8+ifm=KS58vA@mail.gmail.com>
To: ntp@ietf.org, draft-roughtime-aanchal@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d562eb058a06c356"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ZcwRrIHKJScTTD5KQB-TDdQVI8g>
Subject: Re: [Ntp] I-D Action: draft-roughtime-aanchal-02.txt
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: Wed, 29 May 2019 13:29:12 -0000

Dear authors,

Thanks for updating the draft. The new text in the Introduction is highly
appreciated, and addresses some of the concerns I raised.

Comments:
1. The document is still missing a threat analysis. There should probably
be a dedicated section that describes the threats that are and are not
solved by Roughtime.
2. In IETF 104 the authors and Kristof explained that delay attacks are
mitigated by measuring the RTT and comparing it to a pre-configured upper
bound. This should be described in the draft.
3. The draft should discuss upper bounds on how "bad" a server can be
without being detected as a falseticker.

Some proposed text follows.

Cheers,
Tal.


Here is some (preliminary) proposed text for (2) above:

Although delay attacks cannot be prevented, they can be limited to a
predetermined upper bound. This can be done by defining a maximal tolerable
RTT value, MAX-RTT, that a client is willing to accept. A Roughtime client
can measure the RTT of every request-response handshake and compare it to
MAX-RTT; if the RTT exceeds MAX-RTT, the corresponding server is assumed to
be a falseticker. When this approach is used the maximal time error that
can be caused by a delay attack is MAX-RTT/2. It should be noted that this
approach assumes that the nature of the system is known to the client,
including reasonable upper bounds on the RTT value.


Here is a preliminary proposal for some text for (3) above (needs to be
reviewed and discussed):

As discussed in the introduction, the absence of proof of malfeasance does
not indicate that all the servers are "good". However, if the Roughtime
mechanism indicates that all servers are well-behaved then Roughtime
timestamps can be used to compute an upper bound on the time error of a
potential falseticker. For example, for a given set of responses (r_1, r_2,
r_3) from three servers, if it is guaranteed that server 1 and server 3 are
truechimers, then the client has an upper bound on the time error that may
be caused by the reply from server 2, as the timestamp of server 2 is
bounded by the timestamps of server 1 and server 3. Thus, the time error
from server 2 cannot exceed:

max{MIDP_3 - MIDP_2 + RADI_3 + RADI_2,
    MIDP_2 - MIDP_1 + RADI_2 + RADI_1}.

More generally, if n servers are used in the protocol, and for a given set
of responses (r_1, r_2, ..., r_n, r_1'), if server 1 is guaranteed to be a
truechimer, then the time error that may be caused by each of the servers
2, 3, ..., n is bounded by:

MIDP_1' - MIDP_1 + 2*RADI_1


On Mon, May 27, 2019 at 8:03 PM <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network Time Protocol WG of the IETF.
>
>         Title           : Roughtime
>         Authors         : Aanchal Malhotra
>                           Adam Langley
>                           Watson Ladd
>         Filename        : draft-roughtime-aanchal-02.txt
>         Pages           : 11
>         Date            : 2019-05-27
>
> Abstract:
>    This document specifies Roughtime - a protocol that aims to achieve
>    rough time synchronization while detecting servers that provide
>    inaccurate time and providing cryptographic proof of their
>    malfeasance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-roughtime-aanchal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-roughtime-aanchal-02
> https://datatracker.ietf.org/doc/html/draft-roughtime-aanchal-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-roughtime-aanchal-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>