Re: [Ntp] Antwort: Re: Antwort: Why Roughtime?

Zhentian Huang <hzt23@mails.tsinghua.edu.cn> Fri, 19 January 2024 08:03 UTC

Return-Path: <hzt23@mails.tsinghua.edu.cn>
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 521ABC14F702 for <ntp@ietfa.amsl.com>; Fri, 19 Jan 2024 00:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.696
X-Spam-Level:
X-Spam-Status: No, score=-6.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mails.tsinghua.edu.cn
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvWOJes6YXFW for <ntp@ietfa.amsl.com>; Fri, 19 Jan 2024 00:03:07 -0800 (PST)
Received: from zg8tndyumtaxlji0oc4xnzya.icoremail.net (zg8tndyumtaxlji0oc4xnzya.icoremail.net [46.101.248.176]) by ietfa.amsl.com (Postfix) with ESMTP id C7973C14F749 for <ntp@ietf.org>; Fri, 19 Jan 2024 00:02:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mails.tsinghua.edu.cn; s=dkim; h=Received:Date:From:To:Subject: In-Reply-To:References:Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID; bh=fkeI/9F+aRrjZZjhNURj1QmZ/VbAUuBlgOTe LJODziw=; b=IbJxWbgq9WSYWiITlnNTxRN3/WrYhOoHSsVDU3DO/RPKHU1CS8Xm FTf9pmvRSQhKHO0+zTv/aikitLK4fQpCeW9mHE+hQF09aEd5peSrCG+mJ0DqsmWE CxTiWJEGF2B7Qp5WQTYNnAzfI+t2Rd0PQtMjFPE3s1AC00Mp6fTMUVk=
Received: from hzt23$mails.tsinghua.edu.cn ( [183.173.186.75] ) by ajax-webmail-web5 (Coremail) ; Fri, 19 Jan 2024 16:02:29 +0800 (GMT+08:00)
X-Originating-IP: [183.173.186.75]
Date: Fri, 19 Jan 2024 16:02:29 +0800
X-CM-HeaderCharset: UTF-8
From: Zhentian Huang <hzt23@mails.tsinghua.edu.cn>
To: Watson Ladd <watsonbladd@gmail.com>, ntp@ietf.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version 2023.2-cmXT5 build 20230915(bf90896b) Copyright (c) 2002-2024 www.mailtech.cn mispb-4df55a87-4b50-4a66-85a0-70f79cb6c8b5-tsinghua.edu.cn
In-Reply-To: <CACsn0ck2Y2tf=KLjy4KORNR=LJXtwodOPN+Gdpa47ZmD7nUDeA@mail.gmail.com>
References: <3adf02c.2124e.18d0ff7655f.Coremail.hzt23@mails.tsinghua.edu.cn> <CACsn0ck2Y2tf=KLjy4KORNR=LJXtwodOPN+Gdpa47ZmD7nUDeA@mail.gmail.com>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-ID: <6a934b1e.17cc.18d20be269e.Coremail.hzt23@mails.tsinghua.edu.cn>
X-Coremail-Locale: zh_CN
X-CM-TRANSID: zAQGZQAH+SuVLKplwLnOAw--.31253W
X-CM-SenderInfo: xk2wjjo6pdxz3vow2x5qjk3toohg3hdfq/1tbiAQUBBWWprbVXugA Bs4
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWUCw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/XBaY2YCDw-sTzgd4zqFans5YE94>
Subject: Re: [Ntp] Antwort: Re: Antwort: Why Roughtime?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Fri, 19 Jan 2024 08:03:14 -0000

> > There are many devices in the whole IPv4 network that need to get time, if all these devices request roughtime from the roughtime server, will the merkle tree be large? How do you consider the storage overhead for merkle tree?
> 
> The merkle tree contains a small number of responses to batch
> signatures and reduce load under heavy traffic conditions. It does not
> store every single request and response.

How many requests are given a signature together at a time?

> >
> > If a malicious roughtime client provides a maliciously generated time chain to a normal roughtime server, is it an attack on the roughtime server and how to detect it?
> 
> It is not an attack, nor does the server know what the chain is: it
> only sees a commitment to the chain.

I'm sorry, I don't quite understand, can you elaborate? Besides, can other clients use this chain of evidence to judge which roughtime server is malicious?