RE: SCRAM methods

[- Neustradamus -]

---

De: Simon Josefsson
Envoyé: Vendredi 03 janvier 2020 16:03
À: - Neustradamus -
Cc: address@hidden
Objet: Re: SCRAM methods

- Neustradamus - <address@hidden> writes:

> Simon, can you add the code on GitHub?
> It will be better and it will be nice to have PRs from other devs...

I'll consider setting up a GitLab mirror of the git repository, but I
prefer not to touch GitHub.

|| You can now work directly on GitLab and create an official mirror on GitHub like a lot of organizations/companies, users/devs...

> -> gsasl clone to fix SCRAM-SHA1 server side.
> - https://github.com/20centaurifux/gsasl/commits/master

That implements what Jeremy suggested in another email (quite
identically actually!), however it has the more fundamental design flaw
that I realized when thinking about this.  So I don't think this is a
good idea.

|| Look year of the commits ;)

> - https://github.com/ClickHouse-Extras/libgsasl/commits/master

This seems to a cmake-based port of libgsasl.  Interesting, but I don't
see any other improvements and I'm happy with autoconf.

> - https://github.com/markpizz/gsasl/commits/master

This has Visual Studio improvements that I would like to see too, but it
is not my priority right now and it is done in a way that makes it
difficult to review or apply.

|| Can you look other GitHub repositories too? No a lot ;)

> I hope a 1.8.2 or 1.9.0 with all changes included SCRAM-SHA-256(-PLUS).

Me too :-)

> If you can add all the family? 224/384/512 too, it will be nice 🙂
> - SCRAM-SHA-1
> - SCRAM-SHA-1-PLUS
> - SCRAM-SHA-224
> - SCRAM-SHA-224-PLUS
> - SCRAM-SHA-256
> - SCRAM-SHA-256-PLUS
> - SCRAM-SHA-384
> - SCRAM-SHA-384-PLUS
> - SCRAM-SHA-512
> - SCRAM-SHA-512-PLUS
>
> It will be possible to have?
> - SHA-512/224
> - SHA-512/256
> - SHA-512/384
>
> But why, for example:
> https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme

I think adding these variants are harmful.  They are not standardized by
the IETF, and I don't even see any proposal to standardize them.  The
SASL framework does not scale well with many different authentication
mechanisms, so there is interop considerations in adding too many of
them.  Unless there is work in the IETF to standardize these, I'm not
going to make this a priority.

|| It is SCRAM-SHA-2 family it is already used in other libs/softs (Cyrus SASL for example).

|| Look all SCRAM informations here: https://github.com/scram-xmpp/info/issues/1

|| I have contacted the draft author, there will have SHA-512/256, he can not change it (badly).

> When 256... will be added, please update the website (http://www.gnu.org/software/gsasl/)
> -> RFC7677
>
> You can already do:
>
> Please change:
>
> - Jabberd2, a XMPP server.
> ->
> - jabberd2, an XMPP server
>
> And remove all "." in the list, it is not needed ->
> - GNU Emacs, in the Gnus MUA
> - GNU Mailutils
> - GNU Anubis
> - MSMTP
> - MPOP
> - VMIME
> - Vortex Library, a BEEP stack
> - jabberd2, an XMPP server

Thank you, applied now!

|| THANKS.

/Simon