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

Benjamin Kaduk <kaduk@mit.edu> Thu, 11 February 2021 04:52 UTC

Return-Path: <kaduk@mit.edu>
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 53EEA3A1178 for <curdle@ietfa.amsl.com>; Wed, 10 Feb 2021 20:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pcZ_DnSproMR for <curdle@ietfa.amsl.com>; Wed, 10 Feb 2021 20:52:49 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CE7A93A1176 for <curdle@ietf.org>; Wed, 10 Feb 2021 20:52:48 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11B4qg9s020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <curdle@ietf.org>; Wed, 10 Feb 2021 23:52:46 -0500
Date: Wed, 10 Feb 2021 20:52:41 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Curdle List <curdle@ietf.org>
Message-ID: <20210211045241.GW21@kduck.mit.edu>
References: <A77E7858-C4ED-4DA0-8015-5E67EB921144@sn3rd.com> <02E82091-15F9-4C36-96AD-1F88CC2E5594@akamai.com> <CAMm+LwgUPBiZ6FoiBir9ByFPFxgcWtMGVKC4LPNVM7EdCaVoDQ@mail.gmail.com> <1612482228184.63328@cs.auckland.ac.nz> <CADPMZDDUe64wXaRENUHv-gVFmQNp2OmBNveSpOFwPxTMLHo8sg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADPMZDDUe64wXaRENUHv-gVFmQNp2OmBNveSpOFwPxTMLHo8sg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/io98lNTDy5ZSbjn3dMK6wan7it4>
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, 11 Feb 2021 04:52:51 -0000

On Sat, Feb 06, 2021 at 02:56:20PM -0600, denis bider wrote:
>
> I think the IETF could ease the registration and documentation burdens to
> increase the likelihood that:
> 
> - Registration happens, for coordination purposes.
> 
> - Documentation is published that otherwise would not be, even if it's not
> perfect.
> 
> I think there are opportunities here that are currently being missed.
> Changing some of the SSH registries to expert review could be a step in
> this direction, but it depends on what the expert review practically looks
> like. If it's going to look like Peter described, where you can't actually
> reach the experts, then I'm not sure if it's an improvement. :)

If the experts are non-responsive, you should escalate to the IESG and hold
the IESG ultimately responsible for the presence of functional experts.

And if we are changing the registry procedures, we can make it so that
there's a designated place (list) to talk to the experts, which is done for
many TLS, OAuth, etc. registries already.


On Sun, Feb 07, 2021 at 10:38:08AM +0000, Peter Gutmann wrote:
> denis bider <denisbider.ietf@gmail.com> writes:
> 
> >For most things, I'm not willing to go through this effort.
> 
> It is an excessive amount of effort in many cases.  Some years ago I assisted
> in the creation of an RFC used by an industry body that amounted to "if you
> see the value 27 in this location, assume X".  The RFC itself was something
> like ten to fifteen pages of IETF-mandated gunk that no-one in the industry
> body knew what to do with, it was only the fact that I sort-of volunteered to

FWIW, I think we're down to maybe 3 pages of gunk now.
https://datatracker.ietf.org/doc/draft-allan-5g-fmc-encapsulation/ is up
for approval this week and is only 8 pages, yet seems to contain a fair bit
of non-gunk.

> do the work that prevented use of the previous approach, "take the last-
> currently-used value and add ten or twenty and hope no-one ever gets to it".
> There'a Laffer curve at play here, and the current process seems to be too far
> off to the right of it.
> 
> Not sure what the solution is, but it should at least be less painful to
> comply with the process than to circumvent it.
> 
> (My suggestion for a Security Considerations section that read "The number 27
> may be offensive to some religions; caution is advised", just so we could say
> something interesting somewhere, wasn't accepted).

That's a shame!

-Ben