Subject: [kitten] Register too long SASL mechs?

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 May 2021 15:48:53 +0200

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.

/Simon

---

From: Simo Sorce <[email-masked]>
Date: Wed, 26 May 2021 12:39:49 -0400

> 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 ?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 May 2021 19:13:06 +0200

> implementation that conforms to RFC 4422 ?

Any implementation that don't support them would reject them as
unknown/invalid.  If it causes a vulnerability, that should be fixed
anyway.  So, no, not really, as far as I can see.

My biggest concern is that if we register them formally, we introduce an
inconsistency with RFC 4422, and should there ever be an RFC describing
them, that ought to extend RFC 4422 to increase permitted length and I'm
not sure that is a good idea.

IANA suggested that we can add a 'Note:' section to the registry where
these mechanisms are mentioned, including that they don't conform to the
particular format imposed by RFC 4422.

/Simon

---

From: Robbie Harwood <[email-masked]>
Date: Wed, 26 May 2021 14:21:00 -0400

Simon Josefsson <simon=[email-masked]> writes:

>>> avoid any interop problems and allowing people to find out what
>>> these are.
>>> 
>>> 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).

I also don't think that refusing registration would help anything.

>>> mechanisms is orthogonal to registration, but would be useful.

Do you know if there's any intent to pursue standardization?  

> not sure that is a good idea.

I'm not sure it has to.  As documentation of something that occurs in
the wild, I think it could note that those names are non-compliant?  It
could also introduce alternate, compliant names for them.

Now that said, I'm not aware of anything significant about 20 here, and
wouldn't oppose just raising the length limit on the basis of "we found
this in the wild and it's not an unreasonable name otherwise".

> particular format imposed by RFC 4422.

The suggestion of a note seems good.

Thanks,
--Robbie

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 27 May 2021 10:28:11 +0100

Hi Simo,

[I sent this message just to Simo by mistake. Resending.]

> 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.

Best Regards,

Alexey

---

From: Simo Sorce <[email-masked]>
Date: Thu, 27 May 2021 09:31:30 -0400

> 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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 27 May 2021 10:05:04 -0400

>    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"

> happening, and IANA can continue with 1).

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 May 2021 17:16:58 +0200

Jeffrey Altman <[email-masked]> writes:

> 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.
>

There is interest from them to standardize something here -- so
effectively this means chosing option 2) now and the standardized
variant will be registered when it is ready.

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

They don't use any normal SASL library but implements a thin SASL layer
themselves.  I don't think many IRC clients/servers use regular SASL
libraries for this, so the fact that SASL libraries are limited to 20
characters doesn't matter.

/Simon

---

From: David Lloyd <[email-masked]>
Date: Thu, 27 May 2021 09:53:59 -0500

> Do SASL implementations not enforce the name length restriction?

Pitching a data point in here as a Java developer: As far as I can tell,
the Java SASL API does absolutely no enforcement of mechanism name length,
so one can generally look up mechanism implementations for too-long names
without any validation errors occurring.  Consequently, unless the protocol
implementation does an explicit length validation, too-long names probably
"just work" for most Java-based, SASL-using applications (and I know for a
fact that we relied upon too-long names in at least one case in the past).

> Do SASL implementations truncate the name to 20 characters?

Not in Java that I've seen.

-- 
- DML • he/him (co-author of the SASL mechanism implementations and
utilities used in JBoss application servers)