Re: [saag] SSH & Ntruprime

Watson Ladd <watsonbladd@gmail.com> Thu, 11 April 2024 02:57 UTC

Return-Path: <watsonbladd@gmail.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 A4A36C14F5FD for <saag@ietfa.amsl.com>; Wed, 10 Apr 2024 19:57:43 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 4jWOTKPYveHD for <saag@ietfa.amsl.com>; Wed, 10 Apr 2024 19:57:39 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 6AE68C14F6A5 for <saag@ietf.org>; Wed, 10 Apr 2024 19:57:39 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-343cfe8cae1so4625710f8f.3 for <saag@ietf.org>; Wed, 10 Apr 2024 19:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712804257; x=1713409057; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=k6GNIJk4te8v4H89znhmQWqHB4gXiB0Btd+pQEY7MxY=; b=LmemcIFodnyQ2ejh3s1iH6qKeHW+MtD6SOf1NAQgOMxRb4skcCa8TNGwaVdXOLnYGK Ihi2djUE7uM9QjkAoGS82M+8vWzEDsbNHGZaNRnlg2BWrYmH/aHOx1l4EIpnO/eKdTHr 2eSMi5gqYVABoUIRJqOBltvaFyJC7PerfJq3g+LEknJPChe6CXX1omW888kyKFaauqHH m8HY6Zn6KZIsD6mM0C2iK6PKwEDL94x3qVH1dQTl+Dfvn1otJwsLlHab7YExwd9uuiLN ATAwb/1LC9o0g78fvENNP8fN4a21IGv+U7cDf7svV63iWcKygBzoFMMrb3jbzwv0akHH QNtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712804257; x=1713409057; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k6GNIJk4te8v4H89znhmQWqHB4gXiB0Btd+pQEY7MxY=; b=WT/ykBJ3fZo1qZDINJtgY1hw+8qIp/S3lAgjLtFOcAYea9fesDPq8HAwLEZuw1Z0ly v57ccD3tRu0ntSftlSjp7rgNSNGxqGukpOC776W7y+LPvlAyGtG6Vrq0M67OVrtq9V7i PybV+eaebo3EOns5VJfYTk+i9AC3HuQq55XYcsjOLHayntY7GlPx+o6ox8p+9HiCqzqk /waiWGecvuBHi7k5YLqtL854tzRjH04AMmLljV+E1tV0tm1GuOSgSr/K9bwkLooIUlrh 7eqaHm4G9mCgcc/mbK/zC8a+Jiz4sWtgCRGCoDGYELtcj5DWpO+F+0MoazbVwLFwB9Kb 6Dug==
X-Forwarded-Encrypted: i=1; AJvYcCWvzUSRDXQrA4pyY1cfPmRoT5bHkfbxLHQ/ZPLvF1lvJgC98qOYKd+yP1fJhDcPYSbtL3b2BD1dnmwrnoHD
X-Gm-Message-State: AOJu0YxlGmdPN/Y/f+IV4Bu/hOEK/FWhAfiyBI20WvGHLbvEv8Ottkg3 20+cF80M/t1WtvADucNHtlrJwVxrOZRvLQGF9neIOit0kTCrJIbq3E2miaL4B3QOu+XhG+IyPdn /b/HTUh/GtsidfDmPcL2nMIiXmgqYAA==
X-Google-Smtp-Source: AGHT+IG/IFkKb7CzDc4wsuhfaUvHsAe+zOnPUcCQGeq/P7W/Fz75odphA4WcYcIBpA6sTbj3ZMbrHvyJT9dyMrhYO7s=
X-Received: by 2002:adf:f081:0:b0:343:b619:dd52 with SMTP id n1-20020adff081000000b00343b619dd52mr2817213wro.0.1712804257014; Wed, 10 Apr 2024 19:57:37 -0700 (PDT)
MIME-Version: 1.0
References: <05D73B77-ECFB-43E9-A2A8-00D46F63FC32@aiven.io> <20240405162821.1801419.qmail@cr.yp.to> <CAGL5yWaJXRDyiQ=w2XJcoFhCQ3JDriqO+jAcOKz7J4kW2PY=uw@mail.gmail.com> <87o7ahzi8c.fsf@kaka.sjd.se> <CABcZeBO-_k3pTsLAqOm3c5F8Cnbnd1mtdpuaoQicoCRBLPZLLg@mail.gmail.com> <d2bd2378-4de4-4426-b2f4-fbcff6de5d2a@cs.tcd.ie> <CABcZeBPtRoGg=diFd2MjRXn0SD+KMJSC65ROe55SpsdcLL_m_g@mail.gmail.com> <9da5e8a6-b329-41cd-89c1-4423f6739341@nthpermutation.com> <CABcZeBN-Oy-vG=VYwqAmd=Fi7AWyp1pQPnMQMhe0-EzOPZwrsQ@mail.gmail.com> <7127f31a-bb6f-467a-aa67-55b46e7f95f2@nthpermutation.com> <3bef7fff-6a84-42ba-a2ee-a5e6bd60c816@cs.tcd.ie> <CANeU+ZDvWWd+HmtXx=4x0zgO6FNfeqwzybU+jjVHzFWqkgz2Rg@mail.gmail.com> <CABcZeBPXDcq-hZnzqD0koFm+Hv130tHvYuWN4QHwmZWtj8-bBw@mail.gmail.com>
In-Reply-To: <CABcZeBPXDcq-hZnzqD0koFm+Hv130tHvYuWN4QHwmZWtj8-bBw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 10 Apr 2024 19:57:25 -0700
Message-ID: <CACsn0cn4=FhT9GupGJ0-3bX8dFQdTGqzvcthziQjEM69n63_SA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "StJohns, Michael" <msj@nthpermutation.com>, Security Area Advisory Group <saag@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/SrSCOG1muQ51ro9ph57tlmOkaD8>
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: Thu, 11 Apr 2024 02:57:43 -0000

On Wed, Apr 10, 2024 at 7:28 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Wed, Apr 10, 2024 at 7:05 PM StJohns, Michael <msj@nthpermutation.com> wrote:
>>
>> On Wed, Apr 10, 2024 at 21:06 Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>> I'll also note the title and content of 8447 says that it
>>> applies to TLS and DTLS registries so I'm confused by any
>>> argument that says that 8447 affects other protocols other
>>> than in the abstract sense that it demonstrates a setup
>>> that could in principle be copied.
>>>
>>> So, WRT this thread: IMO 8447 is fine, but that does not
>>> mean everyone else needs to operate as if they're TLS,
>>> and in particular, 8447 has zero implication for how best
>>> to handle anything to do with SSH.
>>
>>
>> Yup. And had EKR not mentioned RFC8447 might be a good model for SSH earlier in this chain, I wouldn’t be saying anything now.
>
>
> RFC 8447 aside, the text in RFC 9519 [0] appears to me to at least
> implicitly permit registration without any IETF specification at
> all. https://www.rfc-editor.org/rfc/rfc9519.html#section-3
>
>   Expert Review [RFC8126] registry requests are registered after a
>   three-week review period on the <ssh-reg-review@ietf.org> mailing
>   list, and on the advice of one or more designated experts. However,
>   to allow for the allocation of values prior to publication, the
>   designated experts may approve registration once they are satisfied
>   that such a specification will be published. Registration requests
>   sent to the mailing list for review SHOULD use an appropriate
>   subject (e.g., "Request to register value in SSH protocol parameters
>   <specific parameter> registry").
>
> The term "such specification" is ambiguous (and I don't see any other
> text in 9519 about it) but here's RFC 8126 Expert Review says
> about:
>
>    For the Expert Review policy, review and approval by a designated
>    expert (see Section 5) is required.  While this does not necessarily
>    require formal documentation, information needs to be provided with
>    the request for the designated expert to evaluate.  The registry's
>    definition needs to make clear to registrants what information is
>    necessary.
>
> I don't know how the experts have been interpreting this text, but
> I think it's at least arguable that this is consistent with having
> a "specification" just exist somewhere, e.g., on someone's Web page.
> It doesn't seem to require that it be stable, for instance.

In the filing cabinet behind the door below the stairs marked beware of puma?

More seriously I would when interpreting strike out that entire
sentence in RFC 9519 as scrivener's error. The process described
doesn't have a spec, Specification Required is stricter than Expert
Review in RFC 8126, applying all the requirements and more. If the
authors of RFC 9519 had wanted a specification to be required they
knew how to say that consistently, and clues in the text that indicate
they may at one point have wanted to are insufficient to conclude that
the specification is in fact required. But maybe that's wrong and if
someone had noticed this in last call we'd have gone back and changed
to Specification Required.

Sincerely,
Watson Ladd

>
> -Ekr
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag



-- 
Astra mortemque praestare gradatim