Re: [Sidrops] WG Adoption call for draft-harrison-sidrops-manifest-numbers-01 - ENDS 04/15/2024 (April 15 2024)

Rob Austein <sra@hactrn.net> Thu, 04 April 2024 22:58 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D643EC14F5F7 for <sidrops@ietfa.amsl.com>; Thu, 4 Apr 2024 15:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hactrn.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY53puE4NNeB for <sidrops@ietfa.amsl.com>; Thu, 4 Apr 2024 15:58:27 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (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 ietfa.amsl.com (Postfix) with ESMTPS id E90D9C14F712 for <sidrops@ietf.org>; Thu, 4 Apr 2024 15:58:27 -0700 (PDT)
Received: from orthanc.hactrn.net (unknown [IPv6:2601:19c:4f80:ae5:5613:982c:7d32:815c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: minas-ithil.hactrn.net@hactrn.net) by adrilankha.hactrn.net (Postfix) with ESMTPSA id 11CF839811 for <sidrops@ietf.org>; Thu, 04 Apr 2024 22:58:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hactrn.net; s=adrilankha; t=1712271506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=swciJ5UW9eHOkQ5R2WhfPAVwF/NPEW6yA4HVjqsqUS8=; b=hexToPPRjPH2IpBx7QhGgOZO/zKAHvy6lMydM5t+h5y9yhMR+1/huC+Os7hfmDdZCqkoxn k8PQcWw87les9wH07MXs4cauSJc+6NbA4FBdTw63u+QHttt5ulq5BDeCX/lEdruIXlS3n7 25PHsTrDQXpc7avWrfXUfeS8/tWYjd5CIrvOeX+b4v8WqYEsnffB/XhX0tJCn010docZ4p iFVBZo/GlxwnsSBO9DKu6ZGKfknYT0vStrkeY4KMrQVXb/VYvfaWMC2eYp8CXROi1KU9f/ GjUp5HRZBhfqm8gCvnKPjUWCHpHZ0nvessh9nlTSsrhANMUYTQdwUeRksOLwWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hactrn.net; s=adrilankha; t=1712271506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=swciJ5UW9eHOkQ5R2WhfPAVwF/NPEW6yA4HVjqsqUS8=; b=hE0ryuFiWxVWRDO7vOJJSW6mPAaXLBybOpTyJEWqpocThc6OSJbNrwlWd9SrBZV614mirS 9R6JsOB5ZhnFpMM5mhz1BC0Ro37BD0foYkx1diBiyOKuDM7pFAPOM7uMaJEGQ05x3J1k5k bTGgDCilKzVNk+ESAoQwMT406OlE2Tfx9lNVdQGujL4BKYcRwQnzWq+pgyPlxEMY3szR47 w5K1HSyi32CN/MNZoXLT6GTIu2RTNl5JPdFsKEYWkmAReupHuVizWapVYzFndEl2KghudQ eI0bKPlcgol5Ql62mRIdcHP10PvYc2kWL4A/Xi+yc4IDJLcqshqkrU4SVlaUxw==
ARC-Authentication-Results: i=1; adrilankha.hactrn.net; auth=pass smtp.auth=minas-ithil.hactrn.net@hactrn.net smtp.mailfrom=sra@hactrn.net
ARC-Seal: i=1; s=adrilankha; d=hactrn.net; t=1712271506; a=rsa-sha256; cv=none; b=k13Nx+Fz23iHdjnmaOdZxT6tBXAchbRkcxlNJF/AQcHRiJ8ZOg7P1GKgEjKV+zZ5MpOBzh 3ySVk654eK0TfaylNEi3GwUlxLuMiAyr1IkmbVkgxaLrW1UXokqpiVEVceCTKpPMZr6H4u 7N8nqCjRagxoCUuBvkKEI7KZSxvPsWPgS7+DQ9/EBLugLRBBoPSFlkdcqMFzzslRJhXZgR YjZPbtS0qxBF0Hq8pWfTFSy1w1mf8dGWed2DGPSb29pxTsOdqLuEenzhevyJLoodr9yqhc KqoIKlh9SA2tUFGJSmgAD/gaR90nYtwcMBNxbRKE0qm1zMXuJrgNyoxnPB8vOQ==
Received: from orthanc.hactrn.net (localhost [IPv6:::1]) by orthanc.hactrn.net (Postfix) with ESMTP id 71B3F57A2C43 for <sidrops@ietf.org>; Thu, 4 Apr 2024 18:58:24 -0400 (EDT)
Date: Thu, 04 Apr 2024 18:58:24 -0400
From: Rob Austein <sra@hactrn.net>
To: sidrops@ietf.org
In-Reply-To: <Zgwz2HEWQndhRYkg@snel>
References: <4744462D-78D9-45EE-B3A2-06FF329EA87C@arrcus.com> <A77D691F-57BD-4A00-90E6-E61F257B43EB@ripe.net> <Zgwz2HEWQndhRYkg@snel>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20240404225824.71B3F57A2C43@orthanc.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/m2nCf5AuMxPO5uiUvEzImTAKd1c>
Subject: Re: [Sidrops] WG Adoption call for draft-harrison-sidrops-manifest-numbers-01 - ENDS 04/15/2024 (April 15 2024)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 22:58:31 -0000

I support adoption because it's worth discussing.  I'm not yet
convinced that there's a real problem that needs solving here.

On Tue, 02 Apr 2024 12:35:36 -0400, Job Snijders wrote:
...
> 1) The algorithm presented by RFC 1982 ("Serial Number Arithmetic") has
>    a significant shortcoming: there are sequence numbers for which
>    comparison is undefined.

For any given serial number there's exactly one value for which
comparison is undefined.  Given the size of the numbers here, you're
(much) more likely to be struck by lightening before reading the end
of this sentence than you are to hit that case by accident, so if you
ever do hit it you can assume it's an attack. :)

>    I consider arithmetic operations on a number space this large an
>    unwelcome complication to be avoided if possible.

Implementations I've seen use bignums to hold these numbers, and the
computational expense of one additional bignum subtraction would be
lost in the noise compared to the signature check.