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

Watson Ladd <watsonbladd@gmail.com> Tue, 05 October 2021 02:16 UTC

Return-Path: <watsonbladd@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 AD26C3A0E49 for <ntp@ietfa.amsl.com>; Mon, 4 Oct 2021 19:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BO4UpGMJtJzZ for <ntp@ietfa.amsl.com>; Mon, 4 Oct 2021 19:16:53 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 E2FD73A0E45 for <ntp@ietf.org>; Mon, 4 Oct 2021 19:16:52 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id v18so71075193edc.11 for <ntp@ietf.org>; Mon, 04 Oct 2021 19:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/IbQ4XJ6Y7idgto52+IB9vgCAq9DY3CTN7XMqxRBoJs=; b=o/4Eiy87MJE+KOtkw4UiZARX+eyyQpVViZjlwHGvOkCP+SlUk5gH6VzLeEyrRA+AwD xW5wdVQnGe4HwI9lT8ziUHaQdGcGQ2tbSbb6jWSgNAKJTkXOlIIV5KfV5Vowl5/2XXjE lzdScG8LwV3D3GSMWoxxIfIeePN6/cZbCRJ0Re8eQ34C8ZiBioqyQDAyjCnqRqfESax5 VJdkvnts1m30ngrat5kmRyraGKg/YsSebuN/UPBPi4VE9+CiBYGAn/qNRa9yThBPIIct xK2Ccc29KAP7Jbbh89wJvvMfIjk4WDNko8ugy4txMkwcSFqAkveUp1p39nF+PzpaxhVS B1zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/IbQ4XJ6Y7idgto52+IB9vgCAq9DY3CTN7XMqxRBoJs=; b=5BXaTyG3xSTe2/Fyitw4Y26k+Ruf6/tyGyFZzfxJXb/6V8YnXulMlzo//0AJdWvB7I 4SgpBCUL79y2+jRB89Ia6BXH6BlxDYOnugOuHJ8YSmGtKzFTd9m9FbF0pztnuBCrTodc NNYD4D3/tEA2s7NCKetSjS3CHAZt9JuNIUn9hKmQwgfskqrqZPifFW1IcOLFW1CapN75 B4D3t6lCecbN5c2ksCUxKIGl7oyrfWnsVg/Ybfh6cGbPuepek5RmP7kROojccgrGxfnv b3GzF8Zo8VsfTlb8ezO1zQ3WGG/4/YLMas4ZukWLH0C7bdd3CxtIJHgT0UZPWDhtup+S 0vaw==
X-Gm-Message-State: AOAM531wKp2o6OM/Wr5NHhsbFm1EgN7auS/mX2wcxhJLJ39lt4IiytP/ xGGj3qu+fLOZQfei78VHZcfJM/eds/FQcraU0uM=
X-Google-Smtp-Source: ABdhPJyNsTHpKrqavhjWAqZ8/JycRUe6GQqBMICxMexVzT6GxEWFrJZPKRQaY2imc4Y9RrWrDRPUcKA/ECLwerxceqk=
X-Received: by 2002:aa7:c78d:: with SMTP id n13mr1039795eds.137.1633400209378; Mon, 04 Oct 2021 19:16:49 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <615AAD0F020000A100044300@gwsmtp.uni-regensburg.de>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 4 Oct 2021 19:16:38 -0700
Message-ID: <CACsn0c=mDN6-tb=sP60gDgn6XvypxegWaVNd5yFASO74VHwVGA@mail.gmail.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: Danny Mayer <mayer@pdmconsulting.net>, Marcus Dansarie <marcus@dansarie.se>, JP Sugarbroad <taralx@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/sgLZLAkVbdFFItF-wdWW_jbTVic>
Subject: Re: [Ntp] =?utf-8?q?=5BEXT=5D__Danny=27s_Review_=28was_Re=3A_draft?= =?utf-8?b?4oCRaWV0ZuKAkW50cOKAkXJvdWdodGltZeKAkTA1OiB0YWcgY2hhbmdlIG1h?= =?utf-8?q?kes_implementation_more_complex=29?=
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 02:16:58 -0000

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>om>:
> ...
> >> 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.
Sincerely,
Watson Ladd
>
> ...
>
> Regards,
> Ulrich Windl
>
>


-- 
Astra mortemque praestare gradatim