[Ntp] Antw: [EXT] Danny's Review (was Re: draft‑ietf‑ntp‑roughtime‑05: tag change makes implementation more complex)

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Mon, 04 October 2021 07:28 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 7F6563A1215 for <ntp@ietfa.amsl.com>; Mon, 4 Oct 2021 00:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 uzkHrDG4xL_E for <ntp@ietfa.amsl.com>; Mon, 4 Oct 2021 00:28:23 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [194.94.157.149]) (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 907CD3A1213 for <ntp@ietf.org>; Mon, 4 Oct 2021 00:28:22 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F5D0600004F for <ntp@ietf.org>; Mon, 4 Oct 2021 09:28:17 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id 2A477600004E for <ntp@ietf.org>; Mon, 4 Oct 2021 09:28:17 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 04 Oct 2021 09:28:17 +0200
Message-Id: <615AAD0F020000A100044300@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Mon, 04 Oct 2021 09:28:15 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: watsonbladd@gmail.com, mayer@pdmconsulting.net
Cc: Marcus Dansarie <marcus@dansarie.se>, taralx@gmail.com, "ntp@ietf.org" <ntp@ietf.org>
References: <CAGZkp1-ZCuSvMyQyWCnE511O8-WL=OXfsTdraKsByMmWC3spVA@mail.gmail.com> <CACsn0ckZmR=k2NAmdyhVOA=V_XQ18AnBUBSTOu+bDXS1YsPpUg@mail.gmail.com> <CAGZkp18eASaF7qvubYpDgzvg643ZXuPwDs9qsiC1P_AVLcywLA@mail.gmail.com> <CACsn0cnjHFwxHT13nMavRFzRteWJ=SORY8v4RCZjdjYP0H3oaw@mail.gmail.com> <7dde7eb3-4dc7-94d3-e63a-6d5d0736b1c2@pdmconsulting.net> <54baf1fa-b138-4eb8-6f4e-99168cf2db7b@dansarie.se> <0a95d35f-f708-4a3c-4ecf-77597c42a7a4@pdmconsulting.net> <CACsn0c=gdQWDumfzeHYYWzXPV4sz4J9mTUtYW+4=KueaHHbGdQ@mail.gmail.com> <79dfd56c-54e8-8b85-ed9d-da9fac71d1f1@pdmconsulting.net> <c95eaafb-f294-a54e-d495-0cf74e574686@pdmconsulting.net> <CACsn0cmks2fdwem1rS+QNzCL1WhNR4890Fi1zpjQrL=E3Y=3fQ@mail.gmail.com>
In-Reply-To: <CACsn0cmks2fdwem1rS+QNzCL1WhNR4890Fi1zpjQrL=E3Y=3fQ@mail.gmail.com>
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/fI3oiVton0YDWJ27b9X5swY_GU8>
Subject: [Ntp] Antw: [EXT] Danny's Review (was Re: draft‑ietf‑ntp‑roughtime‑05: tag change makes implementation more complex)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Oct 2021 07:28:36 -0000

>>> Watson Ladd <watsonbladd@gmail.com> schrieb am 28.09.2021 um 03:48 in
Nachricht
<CACsn0cmks2fdwem1rS+QNzCL1WhNR4890Fi1zpjQrL=E3Y=3fQ@mail.gmail.com>:
...
>> 9. Hashing algorithm in Section 6.3
>>
>> It's not clear why the algorithm can only be SHA‑512. This really should
>> be separately referenced so that if SHA‑512 is considered too week in
>> can be replaced by a different hashing algorithm like say HMAC‑SHA‑512,
>> without having to update the proposed RFC.
> 
> Part of what is required for roughtime is interoperability between all
> servers, auditors, and clients. Using only a single hash function and
> signature, and then migrating entire versions, is a better approach
> than permitting everything.

Why not specify that the only supported hash algorithm for this protocol
version is SHA-512, while later protocol version might require or support
different algorithms?
For completeness the used/expected hash algorithm could indicated by a tag
even in this version, maybe providing a mechanism how to allow/require
different algorithms in a later version.
That design would avoid some bad compatibility designs in a later version
(like NTP's "famous" extension fields).

...

Regards,
Ulrich Windl