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
- [kitten] Register too long SASL mechs? Simon Josefsson
- Re: [kitten] Register too long SASL mechs? Simo Sorce
- Re: [kitten] Register too long SASL mechs? Simon Josefsson
- Re: [kitten] Register too long SASL mechs? Robbie Harwood
- Re: [kitten] Register too long SASL mechs? Alexey Melnikov
- Re: [kitten] Register too long SASL mechs? Simo Sorce
- Re: [kitten] Register too long SASL mechs? Jeffrey Altman
- Re: [kitten] Register too long SASL mechs? Simon Josefsson
- Re: [kitten] Register too long SASL mechs? David Lloyd