Re: [kitten] Register too long SASL mechs?

Jeffrey Altman <jaltman@secure-endpoints.com> Thu, 27 May 2021 14:05 UTC

Return-Path: <prvs=178167a757=jaltman@secure-endpoints.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DBC3A0DAE for <kitten@ietfa.amsl.com>; Thu, 27 May 2021 07:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.com
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 J0JDie5A1MJD for <kitten@ietfa.amsl.com>; Thu, 27 May 2021 07:05:11 -0700 (PDT)
Received: from sequoia-grove.ad.secure-endpoints.com (sequoia-grove.secure-endpoints.com [IPv6:2001:470:1f07:f77:70f5:c082:a96a:5685]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B550E3A0DA1 for <kitten@ietf.org>; Thu, 27 May 2021 07:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; r=y; t=1622124309; x=1622729109; i=jaltman@secure-endpoints.com; q=dns/txt; h=To: References:From:Organization:Subject:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding; bh=AXKnrr6f9Zr99TQanhauboaCiGsq9xvmA/ M4/bmkVcM=; b=XnMX/rXNQPIoqVZ27d3wh2XLNvnJyd4N1375hRTJicp6I87suq zMEAvGmJUa5azuHO98dO4kl3mC9LRW4lbZ1gSpG2l66+7bW3Bc+6cHNSc89FYtko BwOSGkGefYRn+zTu8fOkBxm3DgJTBYVm/kmj6cPyiiTNILr+9vewENc/w=
X-MDAV-Result: clean
X-MDAV-Processed: sequoia-grove.ad.secure-endpoints.com, Thu, 27 May 2021 10:05:09 -0400
Received: from [IPv6:2603:7000:73d:4f22:697f:706d:e40d:1bbf] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v21.0.2) with ESMTPSA id md5001002938847.msg; Thu, 27 May 2021 10:05:07 -0400
X-Spam-Processed: sequoia-grove.ad.secure-endpoints.com, Thu, 27 May 2021 10:05:07 -0400 (not processed: message from trusted or authenticated source)
X-MDRemoteIP: 2603:7000:73d:4f22:697f:706d:e40d:1bbf
X-MDHelo: [IPv6:2603:7000:73d:4f22:697f:706d:e40d:1bbf]
X-MDArrival-Date: Thu, 27 May 2021 10:05:07 -0400
X-MDOrigin-Country: United States, North America
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Return-Path: prvs=178167a757=jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kitten@ietf.org
To: "Simon Josefsson (simon=40josefsson.org@dmarc.ietf.org)" <simon=40josefsson.org@dmarc.ietf.org>, kitten@ietf.org
References: <87im35a9mi.fsf@latte.josefsson.org>
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
Message-ID: <b6e58ea8-2f9e-56c7-266c-f423f5368310@secure-endpoints.com>
Date: Thu, 27 May 2021 10:05:04 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <87im35a9mi.fsf@latte.josefsson.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-MDCFSigsAdded: secure-endpoints.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/NdqWJ8aPv8CqEl-JboAvuP8CjNk>
Subject: Re: [kitten] Register too long SASL mechs?
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2021 14:05:16 -0000

On 5/26/2021 9:48 AM, Simon Josefsson 
(simon=40josefsson.org@dmarc.ietf.org) wrote:
> Hi!  There is a request to register the ECDH-X25519-CHALLENGE and
> ECDSA-NIST256P-CHALLENGE mechanism names in the IANA SASL registry.  The
> policy is First Come First Serve, so there is no real requirement of a
> standard or anything, however the names are longer than the 20 character
> limit imposed by RFC 4422.  Supposedly these are already deployed and
> have been used in the wild for a couple of years already.
> 
> Some references:
>    https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

The registration page explicitly mentions the 20 character limit

>    https://github.com/atheme/atheme/blob/master/modules/saslserv/ecdh-x25519-challenge.c

2019

>    https://github.com/kaniini/ecdsatool#mechanism-spec

2016 - described as "proposed"

> As far as I can see, we have some options:
> 
> 1) Just let IANA register these names even if they are non-compliant.
> 
> 2) Don't formally register them but mention them on the IANA page to
> avoid any interop problems and allowing people to find out what these
> are.
> 
> 3) Refuse registration since tey are non-compliant.
> 
> I prefer 2) but could live with 1) as well.  I don't think it is in the
> best interest of anybody that registration is refused on technicalities.
> Maybe this post is sufficient to make relevant parties aware of what is
> happening, and IANA can continue with 1).
> 
> Thoughts?

There is a fourth option.  A request for registration implies that the 
mechanisms are actively supported.  We can require that they register a 
RFC4222 compliant name and implement that name.  They will need to of 
course support accepting both the "too long" name and the registered name.

On the registration page a note could be added next to the registered 
name with the "too long" name and the mechanism version in which the 
name was fixed.

Continued use of "too long" names is an interoperability risk for their 
end users.

Am I curious how the "too long" names are working today.

Do SASL implementations not enforce the name length restriction?

Do SASL implementations truncate the name to 20 characters?

Jeffrey Altman