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

Danny Mayer <mayer@pdmconsulting.net> Thu, 07 October 2021 14:34 UTC

Return-Path: <mayer@pdmconsulting.net>
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 D269A3A07EC for <ntp@ietfa.amsl.com>; Thu, 7 Oct 2021 07:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 XGsm41jtjfvR for <ntp@ietfa.amsl.com>; Thu, 7 Oct 2021 07:34:31 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (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 217B83A07A5 for <ntp@ietf.org>; Thu, 7 Oct 2021 07:34:27 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4HQDNZ0F6rzMNXK; Thu, 7 Oct 2021 14:34:21 +0000 (UTC)
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Watson Ladd <watsonbladd@gmail.com>
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>
References: <CAGZkp1-ZCuSvMyQyWCnE511O8-WL=OXfsTdraKsByMmWC3spVA@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> <615C0CE2020000A1000443AC@gwsmtp.uni-regensburg.de> <45e77584-e493-9475-28bb-dba97a5e5bee@pdmconsulting.net> <E5E1960A-8AD4-4118-9822-6CAC1319AC1F@akamai.com> <CACsn0cmw9gHxz1pa1n-bHGfjiORVy5BJxqNF=45sDwoPkKLO5A@mail.gmail.com> <6520FD84-3332-408C-A253-B38AED05715C@akamai.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <d082c217-7f06-bc85-7191-e76c5f4d7910@pdmconsulting.net>
Date: Thu, 7 Oct 2021 10:34:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <6520FD84-3332-408C-A253-B38AED05715C@akamai.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/sYjN43luY_ZSbCe4_RL8NNx2a9g>
Subject: Re: [Ntp] =?utf-8?q?Antw=3A_Re=3A_=5BEXT=5D_Danny=27s_Review_=28was_?= =?utf-8?b?UmU6IGRyYWZ04oCRaWV0ZuKAkW50cOKAkXJvdWdodGltZeKAkTA1OiB0YWcg?= =?utf-8?q?change_makes_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: Thu, 07 Oct 2021 14:34:36 -0000

On 10/7/21 8:56 AM, Salz, Rich wrote:
> I think that if you are going to make that argument, you need to make it very clearly and explain why "algorithm agility" does not apply.
>
> At a minimum, why not include the digest identifier in the messages?

I agree.

Danny

>
> On 10/6/21, 10:43 PM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>
>      On Tue, Oct 5, 2021 at 9:10 AM Salz, Rich <rsalz@akamai.com> wrote:
>      >
>      > >    That was my point. You can put an ID into the protocol to reference the
>      >     hashing algorithm used which references an ID maintained by IANA. That
>      >     way the protocol doesn't change if you need to replace the protocol.
>      >     It's okay to reference a minimum required protocol in the document
>      >     provided that can be updated if the algorithm becomes compromised. I'm
>      >     sure you can find a list of supported hashing algorithms on IANA.
>
>      I think it's important to understand the reality of negotiation. We
>      have to have roughtime 1 and roughtime 2: Clients that support both
>      can discover what a server supports and use the highest supported
>      version.
>
>      Now if we say that we must have Hash X and Hash Y we must then have
>      another negotiation mechanism. But why? If hash X is broken, define
>      roughtime 2, exactly the same as roughtime 1 but with X replaced by Y.
>      In TLS we've found that it is very difficult to make negotiation work,
>      and that using a single well-trod mechanism is better than a wide
>      variety. Why do we need both Hash X and Hash Y? We don't. If a signer
>      is signing data hashed with hash X and hash Y is that secure? It's not
>      usually considered! Now, if there is a good reason SHA-256 would be
>      preferable we can use it.
>
>      While TLS supports a lot of junk, in practice people would like to
>      support very few ciphersuites, and only 3 signature algorithms are
>      permitted for the Web PKI. For Roughtime it's essential to maximize
>      compatibility between servers, clients, and auditors and having
>      versioning is necessary. Additional extension points for the core of
>      signing and verifying time correctness run the risk of fragmentaton.
>      Furthermore what we've seen with TLS is that configurable, pickable
>      suites lead to persistence of bad choices, and aren't understood.
>
>      Sincerely,
>      Watson Ladd
>
>      --
>      Astra mortemque praestare gradatim
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp