Re: [saag] SSH & Ntruprime

Michael StJohns <msj@nthpermutation.com> Mon, 25 March 2024 19:33 UTC

Return-Path: <msj@nthpermutation.com>
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 B2B06C14F6BA for <saag@ietfa.amsl.com>; Mon, 25 Mar 2024 12:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=nthpermutation-com.20230601.gappssmtp.com
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 fEQjFMHb-AWs for <saag@ietfa.amsl.com>; Mon, 25 Mar 2024 12:33:00 -0700 (PDT)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 D88F5C14F701 for <saag@ietf.org>; Mon, 25 Mar 2024 12:33:00 -0700 (PDT)
Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-690d7a8f904so51943046d6.1 for <saag@ietf.org>; Mon, 25 Mar 2024 12:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1711395179; x=1711999979; darn=ietf.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=G6f/l15/dY3p9N15oj/72Ff+HW8i6X2DcpEFBsk2k6Q=; b=cvGVEGBty2TwFeXfASfvsYS8uigK6Ulu1xyjIUeFTT3xUjX6uaQhtTlPOGajNg0Hdm mATMGrxQQKHekfN8SMPKClS7Ngj+Ky9zHiFsi4cw5F8Y9mhFTPl9wDJ4kPwd3srFzrsQ VcSQuuRz08ThwWKGJWfpIwKzNquBieAS9ZE10wZBDzx4iWhKyWGuqk2o938ffvg1Hb1X TAywq3NHJzqgWLZY6rpZKL6jnbyYyAIb833GkBDoLcf1OxUgD1Rd++HQV/I5//3VFZbG 5f2vv32d+ARPjKnGFbjZhNwg+LjrdmjpKn3Wd0N80RnDHXJd8/H0L4jl6kHZIutSDqJH cONw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711395179; x=1711999979; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=G6f/l15/dY3p9N15oj/72Ff+HW8i6X2DcpEFBsk2k6Q=; b=o/n+groMELT9ucrvHNroxvdq1qWNNe9vmqRhS0Qg71XP1A/1ru/OavHiytcLozGAwc F7Mpos8QWI6tAZqNQNuFt4WuYaVulYLKgy+wgjG6dZOBPBiUk+upUs3tm9xFxAA/5DnS bWvu/tJpdYG5qTlFgfJtRkPvf4dRhEZUwYllj3KE4DUcWlZd020lqCEydHvmlyaMDOnU apYEkvl7m3TeSwatx2izyeB3lL0QfxJVeQ66WRD77qRTRz8/sbefoWmOtITU5LBJ1Tm6 mRRLPiI5unt6uZkBXDhvnnO+onrELaclOkWy5VbDMA93cnQnLZne3/68lklXODGuTb+0 GBMg==
X-Gm-Message-State: AOJu0YyAkhDEamu4XI6yaigv/0vPjC8HQHYdH3Ax+ZdQg3NZZMg0RsB/ NUb246f4ep+QPcsTaFJKAbLNx9k/ArEJ3EuMKWcY/K9TnwDd4Ha1wtKw0Oubc1A=
X-Google-Smtp-Source: AGHT+IHiDU+mtlJW1tWxXTASKG2DBqolgd/Z+njzhb9OSBgS2cfH+sBOV7mQe7S++Lx7/YnDE2QHfw==
X-Received: by 2002:a05:6214:76c:b0:696:4771:9b57 with SMTP id f12-20020a056214076c00b0069647719b57mr11180885qvz.23.1711395179004; Mon, 25 Mar 2024 12:32:59 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-31-156-76.washdc.fios.verizon.net. [108.31.156.76]) by smtp.gmail.com with ESMTPSA id r14-20020a0cf80e000000b0069677500d0bsm3094753qvn.29.2024.03.25.12.32.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 12:32:58 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------09hnLn0cWhugWCbsp4ixojmW"
Message-ID: <872c2d08-14a7-4147-8479-6407c09dc8f4@nthpermutation.com>
Date: Mon, 25 Mar 2024 15:32:56 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "saag@ietf.org" <saag@ietf.org>
References: <CABcZeBPWjXvLh06-DBO3Z0sfeb2hgzqzaSZ-J2-TZ7qesrSraA@mail.gmail.com> <CABcZeBMABJ89T0qY0-9C3xxd=mFfGyCh7_9GKbEUBm6JtR+_ng@mail.gmail.com> <6c491f5c-92da-4fb3-a8b1-da1de27b36a6@lear.ch> <CABcZeBN1w0QU6ug3LcMwC+hTMA_-iOs32FkZe+gpPuFrp1y+JA@mail.gmail.com> <64e81f68-5169-4469-b5a0-2851da912091@lear.ch> <CABcZeBOLKMJb5pw59J072FsfeMFcoz1eZYxa1qpXDLW0nAU0cg@mail.gmail.com> <7b4d38b8-b4c1-412b-8287-bd44d0c512a3@lear.ch> <CABcZeBOQYp49i_JjE7vdg6AjxwyvktW7LFTJ4Mh3jt0bmxxxDQ@mail.gmail.com> <CAN8C-_+QUpU2bTeSFmLB7v1qLirTXtypR2U7D54JeEaeKfSp+Q@mail.gmail.com> <CABcZeBNtE6PtEdmh-2rTC5y9U7yEL8JVNo1HMjZtOQw-DHjXQQ@mail.gmail.com> <88a1bb16-b0ef-49b3-a661-c343b4faa7a9@nthpermutation.com> <CABcZeBOo7e=jgrkMa4iXYy-x_2o6eZjTpEyezQiu7AKHk4ZhFQ@mail.gmail.com> <CAN8C-_JKbJLB6EU+8zUoeUgYVMkR4ErkSdpvuzr4LYoNcRKccA@mail.gmail.com> <180b6873-d917-4a6f-9fa7-b174e0afae66@nthpermutation.com> <49C35FC4-17C2-48BD-86D4-5D18FD9CF860@akamai.com> <2D885F8D-0B31-4338-9D82-AC9AAC23CD51@akamai.com>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <2D885F8D-0B31-4338-9D82-AC9AAC23CD51@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/d876j8mMwSm5y028EWTeBWmXNvs>
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 19:33:04 -0000

On 3/25/2024 3:01 PM, Salz, Rich wrote:
>
> Has the IETF committed itself - through an actual public discussion - 
> of making the IDs archival? Keeping them online - yes.  Keeping them 
> at a fixed URL, I think not and I think RFC8447 was a mistake. 
> Referencing RFC8477 as precedent for Murray's question seems problematic.
>
> If you really want to know, perhaps ask tools-discuss email? Or search 
> the email archives.
>
> Someone sent me a pointer off-line. Thanks to that person, who wishes 
> to remain anonymous :) The IESG issued a statement in October 2012 [1] 
> after starting a discussion the month before [2].  The discussion was, 
> shall we say, “extensive.”
>
> [1] 
> https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-removal-of-an-internet-draft-from-the-ietf-web-site-20121025/
>
> [2] 
> https://mailarchive.ietf.org/arch/msg/ietf/Jea_pkJrsgI1dUWvaNdROPY5KCs/
>
Yup - I remember this.  However, this inapposite (yes, been reading too 
many court filings) to the question of "stable reference" which lies at 
the heart of the RFC 8126 requirement for "Specification Required".

> The intention behind "permanent and readily available" is that a
>     document can reasonably be expected to be findable and retrievable
>     long after IANA assignment of the requested value.  Publication of an
>     RFC is an ideal means of achieving this requirement, but
>     Specification Required is intended to also cover the case of a
>     document published outside of the RFC path, including informal
>     documentation.

The language of the statement at [2] does not provide for a stable 
reference, and allows for the removal of various IDs to a private 
archive under certain circumstances.  [2] DOES end the practice of 
removing expired drafts from the public archive and that was about it.  
It didn't say anything about keeping the public archive at a fixed 
location.  And, indeed, the public FTP archive of IDs is some what 
recently deceased.  There's a wide gulf between the meaning of  "Don't 
delete" and "Archive".

What's the proper cite for a stable ID?  The IANA apparently copies the 
current version over to their own files and references that in the 
registry, but the rest of us generally cite the datatracker page, or 
occasionally one of the archived .txt, .xml, .html or .pdf versions of 
the document as appropriate.  Or in the past, the tools page which was 
at times much more useful that then the datatracker.

I understand what 8447 wanted to accomplish, I just don't think it went 
about it the right way.  I don't think it should be a precedent for 
future documents without actually writing down the backing requirements 
and making sure they're institutionalized across the IETF organizations.

Later, Mike