Re: [Curdle] Time to Review IANA SSH Registries Policies?

Tero Kivinen <kivinen@iki.fi> Thu, 04 February 2021 23:15 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D063A194A for <curdle@ietfa.amsl.com>; Thu, 4 Feb 2021 15:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7BVNutq7nLW for <curdle@ietfa.amsl.com>; Thu, 4 Feb 2021 15:15:27 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3D83A194F for <curdle@ietf.org>; Thu, 4 Feb 2021 15:15:21 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id C61701B00081; Fri, 5 Feb 2021 01:15:16 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1612480516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LA+0KYjd4GuGMCcS5lpWlsuQ7l6i9IHIjFEHmrZywJQ=; b=q0AwfiLOWjZBnBPblt9C2ceA6hS/TtXBiUheoOr3hlYxRhoEnHh+QWl1D/4RzwjqqTlSkU b7DxZPJMmiJepvLJIzkwV8cny1vH0cZ4WTq9oIgqD0eHA7cva3E8cI3QjDuCYtJ0kzr83s ibdnZ+ujFITckajHhIzcSaduxOJE33dmeqoHkcxdvwyChBFiS9UWdevPmHnH8oh0Vtfvns oTrE9vbKAtSQTNm7daNsnad+EN3tiLlszRp9kjC77Lt3C9eim2Gv1LHJ/M1O0JVAyhF2PT kVj7WWOlbXsE45v0FBEr6+CgK02tnHx9TiBSFinhB79MjjwSTYkhRPVk5xNvEw==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 7565825C0FAE; Fri, 5 Feb 2021 01:15:16 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24604.32772.431274.534490@fireball.acr.fi>
Date: Fri, 5 Feb 2021 01:15:16 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Jeffrey T. Hutzelman" <jhutz@cmu.edu>
Cc: Sean Turner <sean@sn3rd.com>, SSH List <ietf-ssh@netbsd.org>, Curdle List <curdle@ietf.org>
In-Reply-To: <f1f5c690-f37f-4eca-8834-50b5f44591a7@cmu.edu>
References: <7B98A823-604D-4612-997C-2DC35632901B@sn3rd.com> <f1f5c690-f37f-4eca-8834-50b5f44591a7@cmu.edu>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 16 min
X-Total-Time: 16 min
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1612480516; a=rsa-sha256; cv=none; b=EpEvAtqByxxlAJuKYlBpggaVN1qz9wbjADvL0LHS8s1YJNpUeh95XdB8a5mu7G50Mbo+nu PrhSD2UlzW0LUt0xeEdm03+WyWe5VLxk9fqOhxOWqNNgbM8gthem9WN9/g+/PRcgWvJSfs PrxdK59bAzgtWFLCsC+NDVyIeXIsNbIets4moHl06OnAQphjoZIsxl9fUK4OWe4toS4qZr pyINdAL9n49f5+GGbvcrYRiC1o4CeaWKXNsaV/ufPtYEg54NbCo8qLkUR2huxItn2+Zonq RSAqYukrTpXe2Zew3WH6ugqeU7eXqj+rVITN3oPLbe7sLx7UKwO/ibnqUsJvig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1612480516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LA+0KYjd4GuGMCcS5lpWlsuQ7l6i9IHIjFEHmrZywJQ=; b=FUQADWI3xewpIcL+WghOPp1/HccBrk7glPyjhYfZXOlBYZ+nh7aMfxA9yOM6nPLy1zQQbU Y7jkniWdoZ+mSnK44B6Xjmz5ZKRTIpHk7hiOlio/pgrvZIOyuwNU/R0fBqITvwEkeLbhfT zLBsiTt/RU8hCuqn2y0pQ6ro01bsi+UlYlVvgDMVjU+NFy31fRRAcFc8rSGS5ve5+aPi4d f1VU+uX+iY2TUFOGqLaAGndyedf+ofQJ5Xhv3DaJYgOXpZGHttSDL3Nvnb/NZGt8sSB74I GUr52yK58MS7bnizDsPnqMGl80/YDs1yhlD5yDGYFYE+xweXC47eiasRPX4w5w==
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/oQT9VdPQSnUduma1Ftk1uDoj-FU>
Subject: Re: [Curdle] Time to Review IANA SSH Registries Policies?
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2021 23:15:30 -0000

Jeffrey T. Hutzelman writes:
> I'm not specifically opposed to this, but many of ssh's registries are for
> string identifiers (e.g. algorithm names) where there is a straightforward
> mechanism for individual implementors to define unique, interoperable
> identifiers without going through the registry (specifically, identifiers of
> the form name@domain are permitted, as assigned by the owner of that domain).
> 
> Certain values, such as message numbers, are small, and thus scarce. The
> current policy for these is Standards Action, which IMHO is appropriate giving
> the size of the available namespace as well as the core protocol functions
> they serve. For the most part, it is intended that new values for these codes
> would be allocated only as part of a revision of the base protocol suite,
> rather than in an extension.

I agree on what was said above. I do not think changing those string
registries to Expert review would really help anything, as the corrent
way way of allocate my-favorite-cipher-191-bits-long@kivinen.iki.fi is
much easier than even to go to the Expert and ask for the review... On
the other hand if that algorithm gets implemented by multiple
implementations then writing and RFC about it is not high bar.

Most of the Expert review allocations end up having RFCs anyways
(speaking as an IANA expert for IPsec), or at least have some stable
reference in some other SDOs.

Currently only Message Numbers, and Publickey Subsystem Status codes
have Standards Action registration procedure, and I think at least
Message Numbers should be kept with that high bar.

> That said, there are some other attributes (particularly, disconnect reasons,
> channel open failure reasons, and extended channel data types) for which
> significant namespace is managed under the IETF Review policy, with a small
> portion set aside for private use. It does seem like it would be reasonable to
> update these to use Expert Review instead.

Yep. Those registries do not have string format, so lowering the bar
there from IETF Review to Expert review could be helpful. Perhaps even
the last numeric registry Pseudo-Terminal Encoded Terminal Modes too.

On the other hand only following registries have had any allocations
after the initial work finished around 2006.

  - Message Numbers (integer)
  - Pseudo-Terminal Encoded Terminal Modes (integer)
  - Connection Protocol Subsystem Names (string)
  - Key Exchange Method Names (string)
  - Encryption Algorithm Names (string)
  - MAC Algorithm Names (string)
  - Public Key Algorithm Names (string)

And my understanding is that those string registries used @domain name
format for some time before someone actually decided to create RFC to
register those things, so this did not cause any issues on the
interoperability.

Usually the problems have been when people have used those @domain
name formats, and there is no documentation how they work, thus others
have had to reverse engineer or guess how they work, and didn't get
things right. Requiring RFC solves that issue, as then you must have
a documentation what that thing means...

> The ultimate question, then, is whether it is worth the (admittedly
> small) effort.

I would almost think it would not even be worth the effort. At least
we should show that it has caused some issues in the past before we
invest too much time on this.
-- 
kivinen@iki.fi