IETF Logo Mail Archive

Re: [saag] SSH & Ntruprime

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 26 March 2024 10:11 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 364EAC14F69A for <saag@ietfa.amsl.com>; Tue, 26 Mar 2024 03:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=sandelman.ca
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 29QWLxhf1J7c for <saag@ietfa.amsl.com>; Tue, 26 Mar 2024 03:11:38 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DD6C14F694 for <saag@ietf.org>; Tue, 26 Mar 2024 03:11:37 -0700 (PDT)
Received: from dyas.sandelman.ca (60-240-91-174.static.tpgi.com.au [60.240.91.174]) by relay.sandelman.ca (Postfix) with ESMTPS id 6E6BB20B49 for <saag@ietf.org>; Tue, 26 Mar 2024 10:02:44 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="NWlM2L61"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id A0BE8A1918; Tue, 26 Mar 2024 05:37:35 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1711395455; bh=/e6C9La20Oc0x4C8uqghYwiOuquqgABP/iBTXMspliA=; h=From:To:Subject:In-reply-to:References:Date:From; b=NWlM2L61llBTvuaN0/GfRukJQsgWzXi5N3wk+kg1KTl32Nw5N35LYhUD/UYQXunDV wpPcIolJ+RLjctZplWXmp+v2p1loA5H7Zvr2bewEtbT6LkpbF507kLzQpERG5A2Z4O b7/CvWAvM3cMf3ou6XHw1Q1PtLs+5qe6vXQnWZPvWrx2QdiSn0diZQpD8nCEKJps6W 2Ly0Qdmm20Ca9EKCsFZt4z8B9jm7sColeoplugnc1wLC/TlVpgKRkKMvRtyEzmbZMg ZnNeILnyOaD4ckwK1HKYpRI1rUZKhhhqjy4HLSlxUJhF897KBbBFlYTBfwK6gzNVJ/ IysgArOp2YPHg==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 9E1ADA1916 for <saag@ietf.org>; Tue, 26 Mar 2024 05:37:35 +1000 (AEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: saag <saag@ietf.org>
In-reply-to: <CABcZeBMABJ89T0qY0-9C3xxd=mFfGyCh7_9GKbEUBm6JtR+_ng@mail.gmail.com>
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> <8caa2d4d-bc80-4fcf-b8bc-839052371730@lear.ch> <CABcZeBMABJ89T0qY0-9C3xxd=mFfGyCh7_9GKbEUBm6JtR+_ng@mail.gmail.com>
Comments: In-reply-to Eric Rescorla <ekr@rtfm.com> message dated "Mon, 25 Mar 2024 06:46:30 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 26 Mar 2024 05:37:35 +1000
Message-ID: <422352.1711395455@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/SeAZ7AYW8yVQZc_zmnA-KqZ9irE>
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: Tue, 26 Mar 2024 10:11:42 -0000

Eric Rescorla <ekr@rtfm.com> 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.
    >>
    > [Citation needed].

    > Do you have any concrete examples of when an algorithm has been specified
    > by ID and then someone has been confused about how to implement it?

Not quite the same, but in openpgp, we have a case where a (formerly WG
adopted) I-D was updated for quite a number of years after the WG had been
closed.  That was a bug in the datatracker that it allowed that.
The updates did not have WG consensus, but appeared to.

I don't see a problem if a *specific* I-D (foo-04, not foo) is referenced in
the Registry.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.23.0 | Report a Bug | By Email