Re: [saag] SSH & Ntruprime

Eliot Lear <lear@lear.ch> Mon, 25 March 2024 07:20 UTC

Return-Path: <lear@lear.ch>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705D2C14F68B; Mon, 25 Mar 2024 00:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level:
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 esZB3pK8FOMh; Mon, 25 Mar 2024 00:20:30 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (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 CCC4CC14F5E2; Mon, 25 Mar 2024 00:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1711351223; bh=wQX624vPURWVh03aXQ9SX02Aax2IFvHNtvFv16ZHTJw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NRjJrrSjKyaDB13ew206r5hhx/C5JM0YqfC+zP5LaIpSd9B+I2uo83wpC9z/LSGpk XfApY4jH7g93zwaXaakk8mZUVR/sB4hiGQjr/3Pj4Eg0HORV4RaMYOxn2tEfBBLxjR c14zLk2+zES/VHUprp7/EB9JQbzh4J9cCq3F6WSE=
Received: from [192.168.0.99] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 42P7KMWb959175 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 25 Mar 2024 08:20:23 +0100
Message-ID: <8caa2d4d-bc80-4fcf-b8bc-839052371730@lear.ch>
Date: Mon, 25 Mar 2024 08:20:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Eric Rescorla <ekr@rtfm.com>, Mark D Baushke <mdb@sonic.net>
Cc: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, saag <saag@ietf.org>
References: <CABcZeBPWjXvLh06-DBO3Z0sfeb2hgzqzaSZ-J2-TZ7qesrSraA@mail.gmail.com> <D0CD341B-523B-48A0-8954-EE7F89113241@aiven.io> <AF7B6F32-9EE6-4810-A99A-833DEA917FA9@sonic.net> <CABcZeBPfXQckpZageogUxTYgX2j_Nr_O3bvf-a-x0S_82BHMxg@mail.gmail.com> <079A0AA3-FA02-440F-ABA0-6AF897570E86@sonic.net> <CABcZeBOxfYR+=61DV1XN0F9nrmbzLR2zq_ZvADw4UUy1uFafzw@mail.gmail.com>
Content-Language: en-US
From: Eliot Lear <lear@lear.ch>
Autocrypt: addr=lear@lear.ch; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNGUVsaW90IExlYXIgPGxlYXJAbGVhci5jaD7CwI4EEwECADgCGwMCHgECF4AWIQSY0L2Q Rh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCHtmtG2dJ6M8KI B/46pFrJX+4Ockl2fHR303ais9Lyx8jv6mXKKOr8WR0UYcJ0syQrhaaZNG1VV98tYQHHK9F5 y7hH4YCsrr3odZ6zoavnx5X1X/2xw8y732f/irVoOOkYLid9IGPxa2e2nYXCZpde5/yvv3we XVE4mG4dEAD5T8iKS4Hz/3fKGJQ15o79Jv92HgC7RpCt0WaiQ0b6acP3PuwjDJzJzLFZzb7j IiB3izxQESSWE1GNRmoAK/k0gW6kmx1/87tQENrK+3Nn4CJSFQWF6entLnY7UeVm95wbMQkJ evwddDWUO2huDbmZnmxgKXGzSSpuNq7n8ICAOlbt0HfdJAZQfy25bwvezsBNBFMe1UQBCAC0 WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Macj9le20EA5A1BH7PgLGo HOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U7bKeUNRiPFx3YdEkExdd qV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcYY/jB0JEJGyhS5aEbct5c HUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU+tIFBoe3iTp1AUfJcypu cGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5ABEBAAHCwF8EGAECAAkF AlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c62pWpBHHTgxr/32zevxHS iXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnXHXF5Zz2T04X7HnlIVJGw f2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycjPAu7xxKplBs1/IEwmDoA MjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPFOmDhJSmH55HLAky2Mlmq JYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt2mGfIyl0FVdF9hvWPjNR zGbgqoT1Di03RQ==
In-Reply-To: <CABcZeBOxfYR+=61DV1XN0F9nrmbzLR2zq_ZvADw4UUy1uFafzw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------MNMU0nSpbjQJU3n76M0NAzvB"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/vCMBOXBrdpfvPHmjRlon6kzW2Jc>
Subject: Re: [saag] SSH & Ntruprime
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 07:20:36 -0000

Hi

On 25.03.2024 01:40, Eric Rescorla wrote:
>
>
> To the contrary, I think it would be fine to add a code point without 
> publishing an RFC.
>
> I simply don't think there is much value in publishing RFCs to 
> document technologies that were not standardize by the IETF. People 
> can just look at the I-D. That's part of the purpose of relaxing the 
> IANA requirements to allow code point assignment without RFC publication.
>
I disagree.  We have had this conversation elsewhere and internet-drafts 
make a horrible way of memorializing anything, even if old ones can be 
found on our sites.  They can lead to confusion when used with IANA 
registries, especially if updates are later made.

That being said, not every allocation needs to be documented by an RFC, 
but every allocation that requires a specification should use a stable 
reference that we have some confidence will not change.

Eliot