IETF Logo Mail Archive

[Ntp] Antw: Re: [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> Tue, 05 October 2021 08:29 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 509863A08F3 for <ntp@ietfa.amsl.com>; Tue, 5 Oct 2021 01:29:31 -0700 (PDT)
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 mOmBJE2sr5tJ for <ntp@ietfa.amsl.com>; Tue, 5 Oct 2021 01:29:28 -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 25F163A08ED for <ntp@ietf.org>; Tue, 5 Oct 2021 01:29:27 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 61F356000051 for <ntp@ietf.org>; Tue, 5 Oct 2021 10:29:24 +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 4423C600004E for <ntp@ietf.org>; Tue, 5 Oct 2021 10:29:24 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 05 Oct 2021 10:29:24 +0200
Message-Id: <615C0CE2020000A1000443AC@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Tue, 05 Oct 2021 10:29:22 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: watsonbladd@gmail.com
Cc: "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> <615AAD0F020000A100044300@gwsmtp.uni-regensburg.de> <CACsn0c=mDN6-tb=sP60gDgn6XvypxegWaVNd5yFASO74VHwVGA@mail.gmail.com>
In-Reply-To: <CACsn0c=mDN6-tb=sP60gDgn6XvypxegWaVNd5yFASO74VHwVGA@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/JK7DelacLAcluW2JCDzoyCQjcNA>
Subject: [Ntp] Antw: Re: [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: Tue, 05 Oct 2021 08:29:32 -0000

>>> Watson Ladd <watsonbladd@gmail.com> schrieb am 05.10.2021 um 04:16 in
Nachricht
<CACsn0c=mDN6-tb=sP60gDgn6XvypxegWaVNd5yFASO74VHwVGA@mail.gmail.com>:
> On Mon, Oct 4, 2021 at 12:28 AM Ulrich Windl
> <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>
>> >>> 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?
> 
> I'm happy to add that sentence: it means nothing. Future protocols can
> change a lot of things.
> 
>> 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).
> 
> I'm not sure why the hash function is so worthy of singling out here,
> perhaps you can explain more. The intention is every version has its
> own single signature algorithm.

If that is part of the design, say so. However having to start a new
incompatible protocol version just to replace a hash algorithm is bad design
IMHO.
Imagine SSL/TLS had a new or different version for every hash algorithm that
is supported.

Regards,
Ulrich

> Sincerely,
> Watson Ladd
>>
>> ...
>>
>> Regards,
>> Ulrich Windl
>>
>>
> 
> 
> -- 
> Astra mortemque praestare gradatim

v2.23.0 | Report a Bug | By Email