Re: [saag] SSH & Ntruprime

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

Return-Path: <msj@nthpermutation.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A937CC1654EC for <ietf@ietfa.amsl.com>; Mon, 25 Mar 2024 11:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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] 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 sEJeCl7KStJl for <ietf@ietfa.amsl.com>; Mon, 25 Mar 2024 11:49:56 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 793B3C15170B for <ietf@ietf.org>; Mon, 25 Mar 2024 11:49:56 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-69107859bedso31534686d6.2 for <ietf@ietf.org>; Mon, 25 Mar 2024 11:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1711392595; x=1711997395; 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=941DtTVtSeoSgUN9qCDb24W8GN8QCerlpsdQz46L6Q0=; b=AvVTFhqK6R4NXohp9o2pvGar35NpNiDS+QgDRbRG4iGCkAA7Chpga2JE1m+s8IcDZV QumKqnxAVimHYILfK3aoUFgjXvW7T8g5WT0+cTQY2NqnKt6Uv25iz1Opf5nSOFwQb9x5 l76vGFHtcbQ+acqlTlxMWKbB4ifxIighePD/MxsoqTKEbMH3+sSgm7Y1Xig2HWp3Va08 Q1arxSE18XRBFV3D8iL3+LPC5Q2FQOOA1wLBGFwhKt+3Y4G7S4XbY7Hjhgwp+1eO2Wq7 eIzhtTX2CwUgOEQzf6389vANsjQTcocNBeHRyJqG6SIBYr0QxF3r7f8vAqpKXD5GRiP7 qSkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711392595; x=1711997395; 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=941DtTVtSeoSgUN9qCDb24W8GN8QCerlpsdQz46L6Q0=; b=BxB8XdzueHsfnctiY+lUUhDZfBuVO/URV2rDGa44Mm2TcUEWwTrXpIMFLcyTNgPcQj ZIdatrG3WZO/0+S7ToZDzhzY6B9E3DtEusgLkbFwwwx/JxpBrEC9nd/j/ApkUeRkZg4t u3Kf219ohQvHAP5c+Y112EhDcqtrOUMyzPfMBXKKuQcvFsJC0CaKKy9HDeLh7J11A1qb Zt/KXbmZTzN3+z8rCc2mjNsesbwfgFPrMYboCmjPWeaGU3lPl3CuxEb/wM/h2VdYqOaQ +575VFg7FFJGn4iCE1S5weUz2l+wRdWLtS9ZmBrwZScQPHFnkNNZSKLNXwi0+sy4WlP3 826w==
X-Forwarded-Encrypted: i=1; AJvYcCV9qY6xaRR1LWgmTowa2sxjNIcrOGxT+ctdzv3YXgaqMf5z9bcabPTtgM1f2NWWHN3Ph10Hj0iYdm94pFUY
X-Gm-Message-State: AOJu0YzqIJTIrO0Ihk+hUmfgXJTctFUk52Cbw4FMHcAkf7mxwnbRmJjc edqFeVCCDMu1C60gpplSQpit7zHHwb7loZ9feUjDRZyke0m0QJM6ucrMBuhH/ceonJlo45B+cVh m
X-Google-Smtp-Source: AGHT+IEP5Z1ZnFoCgI4YtlLedrQ7UN63NgV8WJlw7KalAOlkAMgjimCWgO4y6WzuE236OIkesQh55Q==
X-Received: by 2002:a05:6214:c88:b0:696:8ecf:e09 with SMTP id r8-20020a0562140c8800b006968ecf0e09mr523865qvr.65.1711392594744; Mon, 25 Mar 2024 11:49:54 -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 ph16-20020a0562144a5000b006967ba7f1adsm2832787qvb.96.2024.03.25.11.49.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 11:49:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------3Hja2593ren98yJAMbvpySFG"
Message-ID: <5f281744-d23e-4c54-aabd-741ba2952e45@nthpermutation.com>
Date: Mon, 25 Mar 2024 14:49:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [saag] SSH & Ntruprime
Content-Language: en-US
To: "Salz, Rich" <rsalz@akamai.com>, Orie Steele <orie@transmute.industries>, Eric Rescorla <ekr@rtfm.com>
Cc: "saag@ietf.org" <saag@ietf.org>, ietf@ietf.org
References: <CABcZeBPWjXvLh06-DBO3Z0sfeb2hgzqzaSZ-J2-TZ7qesrSraA@mail.gmail.com> <8caa2d4d-bc80-4fcf-b8bc-839052371730@lear.ch> <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>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <49C35FC4-17C2-48BD-86D4-5D18FD9CF860@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FqmdAQY_C7jOGh_KV-HkC5MP7Xs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 18:49:58 -0000

Context for the IETF list.  A set of IANA notes were included in RFC8447 
that allowed IDs to be considered as satisfying "Specification Required" 
for the purpose of issuing code points in IANA registries.  The IANA 
requires stable references for a Specification Required.  However, to 
quote from the ID boilerplate,  "It is inappropriate to use 
Internet-Drafts as reference material or to cite them other than as 
"work in progress."

These two seem to be in conflict.

On 3/25/2024 2:17 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.
>
> Citing RFC 8447 as precedent is exactly the right thing to do, since 
> it’s a standards-track IETF stream RFC.
>
> I'd recommend revoking the notes on the existing registries that allow 
> references to IDs. And, going forward, request the  IESG  refrain from 
> approving any further notes similar to those on RFC8447 until there's 
> an actual consensus and a plan to support "archivalness" of the ID 
> series (e.g. with a fixed URL and with a firm requirement that closes 
> the path of updating the ID).
>
> It seems a bit premature to recommend actions on the basis of “I think 
> not.”
>
So you're saying that a registry update document that most people don't 
give a damn about (along with SNMP mibs and YANG modules and ASN1 
module) and that probably was seen by maybe a few dozen people if that, 
that had IANA add a note to the registry gets to change the meaning of 
the IDs - as written in the standard boiler plate - from "not citeable" 
to "citeable" for all future RFCs?

To restate "I believe not."  To be clearer, consensus to change major 
things (and this would be a major change) requires informed consensus of 
the community, and I don't believe a fairly opaque note in a WG document 
that most would consider registry boilerplate qualifies.

If you want to do this, I'd suggest you propose a change to the ID 
boilerplate that removes the language: "It is inappropriate to use 
Internet-Drafts as reference material or to cite them other than as 
"work in progress." "   I'd also suggest having a discussion with the 
LLC, tools and IANA on what is actually needed to support that change in 
terms of process, server support and tools support.

Move that change through the IETF mailing list, not the TLS list (and 
definitely NOT the RSWG list).  That will make sure you have the support 
to have stable references for IDs going into the future that aren't 
shredded by a website redo.

Later, Mike