[Ntp] Antw: [EXT] Re: NTPv5 draft

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 10 December 2020 07:23 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.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 2FD883A05AA for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 23:23:13 -0800 (PST)
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, SPF_HELO_NONE=0.001, 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 zNa7-xos1ocH for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 23:23:10 -0800 (PST)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [194.94.157.147]) (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 776D73A0489 for <ntp@ietf.org>; Wed, 9 Dec 2020 23:23:10 -0800 (PST)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0ECF7600004E for <ntp@ietf.org>; Thu, 10 Dec 2020 08:23:08 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id 2754C600004D for <ntp@ietf.org>; Thu, 10 Dec 2020 08:23:07 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 10 Dec 2020 08:23:06 +0100
Message-Id: <5FD1CCD9020000A10003D705@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.0
Date: Thu, 10 Dec 2020 08:23:05 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>, james.ietf@gmail.com, mlichvar@redhat.com
Cc: Dieter Sibold <dsibold.ietf@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>
References: <20201201100305.GK1900232@localhost> <F62C1325-8409-474C-9650-FA96405D0F4B@gmail.com> <20201207104541.GE2352378@localhost> <E0159612-5D83-4A0E-BBD1-1D75C0B49226@akamai.com> <20201207153444.GO2352378@localhost> <1204B871-7728-45DA-B628-8F79BD074A96@akamai.com> <20201208095046.GT2352378@localhost> <D15AF5B4-F976-44D6-B8E7-986E3B8CE23D@akamai.com> <20201208150725.GX2352378@localhost> <6d7daa5e-8537-a3a5-a5c3-2468be4c2918@gmail.com> <20201209083800.GY2352378@localhost> <bcec8d14-9af9-96c1-7e71-39569cb7b0ed@gmail.com> <51D0EEC3-F30E-4A0F-9DBA-B8D2A8CFA959@akamai.com> <42E7D41602000042824A10E1@gwsmtp.uni-regensburg.de> <18374174020000D46A6A8CFC@gwsmtp.uni-regensburg.de> <1C64D458020000B5824A10E1@gwsmtp.uni-regensburg.de> <A4CD014B020000F57BE0EBB5@gwsmtp.uni-regensburg.de>
In-Reply-To: <A4CD014B020000F57BE0EBB5@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/00MhgGQrFMv-h7joXzioKD77yUA>
Subject: [Ntp] Antw: [EXT] Re: NTPv5 draft
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, 10 Dec 2020 07:23:13 -0000

    >>> "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org> schrieb am 09.12.2020
um 15:56
in Nachricht <51D0EEC3-F30E-4A0F-9DBA-B8D2A8CFA959@akamai.com>:
>>  Now, suddenly people talk about some non‑specific issues that have an
>     > unknown solution. Where were you when NTS was designed? And why does
>     > it need to be solved in NTPv5?
> 
> NTS was designed to add security features to an existing protocol without 
> disrupting it.
> 
> NTPv5 should be designed with security built‑in from the beginning.

I think "security" was "built-in" since NTPv3, but:
Was the security srong enough?
Was the security easy to deploy and use?
Did it need shared secrets between different authority zones?

In v4 autokey tried to address some issues, while adding several new

So what should v5 really bring?

Regards,
Ulrich

> 
> Miroslav's draft is just an individual viewpoint.  I would be against the WG

> adopting it because the author seems to be opposed to the design requirement

> I just mentioned.
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp