Re: [kitten] Register too long SASL mechs?

[Simo Sorce <[e-mail]>]

On Thu, 2021-05-27 at 10:28 +0100, Alexey Melnikov wrote:
> Hi Simo,
> 
> [I sent this message just to Simo by mistake. Resending.]
> 
> 
> On 26/05/2021 17:39, Simo Sorce wrote:
> 
> > On Wed, 2021-05-26 at 15:48 +0200, Simon Josefsson 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
> > >   https://github.com/atheme/atheme/blob/master/modules/saslserv/ecdh-x25519-challenge.c
> > >   https://github.com/kaniini/ecdsatool#mechanism-spec
> > > 
> > > 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?
> > > 
> > > Pursuing standardization, or publishing a stable specification, of the
> > > mechanisms is orthogonal to registration, but would be useful.
> > Is there any risk that using those names can cause issues to an
> > implementation that conforms to RFC 4422 ?
> 
> Possibly. RFC 4422 defines:
> 
>    sasl-mech    = 1*20mech-char
> 
> so if an implementation is using a fixed size buffer, there might be 
> some issues.
> 
> It is harder to know whether there are any implementations which 
> actually use fixed length buffer for SASL mechanism names.

Given there may be implementations that explicitly or implicitly may
enforce this limit, perhaps (2) is the correct option?

Legitimizing (via option 1) names that could "break" implementations
doesn't sound great to me, unless there is an intention to change the
standard to allow longer names.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc