Good morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, May 7 2024
at 16:00 UTC in xmpp:council@muc.xmpp.org?join
The Agenda is as follows:
1) Roll call
2) Agenda Bashing
3) Editors update
4) Items for voting
a) PR: XEP-0030: Note known wart
https://github.com/xsf/xeps/pull/1341
b) PR: XEP-0045: Remove conflicting keyword in §7.2.2
https://github.com/xsf/xeps/pull/1342
5) Pending votes
Marvin on
* Issue Last Call on 'XEP-0421: Anonymous unique occupant identifiers
for MUCs' (expires today)
See the spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa…
6) Date of Next
7) AOB
8) Close
Version 1.0.0 of XEP-0398 (User Avatar to vCard-Based Avatars
Conversion) has been released.
Abstract:
This specification describes a method for using PEP based avatars and
vCard based avatars in parallel by having the user’s server do a
conversion between the two.
Changelog:
Accept as Stable as per Council Vote from 2024-04-30. (XEP Editor
(dg))
URL: https://xmpp.org/extensions/xep-0398.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Hi folks,
I'm forwarding this email that was posted to the IETF working group
responsible for SASL improvements, because I think it is quite relevant to
people here, yet many are probably not following the kitten mailing list.
I'm aware that by now most XMPP projects have received feature requests to
implement what are essentially obscure flavours of SCRAM, without much
rationale beyond what can be paraphrased as "the numbers are bigger, and
therefore better".
If we decide to move the protocol and ecosystem beyond SCRAM-SHA-1 (which
is required by the current RFC) and possibly SCRAM-SHA-256, it should be
with the necessary attention paid to interoperability and security. All
current feature requests I've seen lack this.
---------- Forwarded message ---------
From: Simon Josefsson <simon=40josefsson.org(a)dmarc.ietf.org>
Date: Thu, 2 May 2024, 09:20
Subject: [kitten] SCRAM-SHA512 and SCRAM-SHA3
To: <kitten(a)ietf.org>
Hi
I'm seeing push on implementers to add support for these variants, and I
noticed new drafts were published recently. I want to repeat some
earlier concerns. I believe the cost of having these two mechanisms as
standard mechanisms in the ecosystem costs more than any advantages we
would get out of them. There is still no cryptographic attack on
HMAC-MD5, yet alone the HMAC-SHA1 or HMAC-SHA256 that are used in
SCRAM-SHA1 and SCRAM-SHA256 that we are still seeing deployment of.
Adding SCRAM-SHA512/SHA3 variants create additional requirements on
hashed password database formats and APIs, since they are not compatible
with SCRAM-SHA1 and SCRAM-SHA256. Parametrization of security protocols
and algorithms are generally a bad idea as it adds complexity which
reduce security. There is the negotiation interop problem if a server
has one credential but not the other for a subset of users. If some
people are using these variants, I would agree that having them
documented is useful. Then I believe the category should be
Informational rather than standards track, and warnings about the
problems should be added.
/Simon
_______________________________________________
Kitten mailing list
Kitten(a)ietf.org
https://www.ietf.org/mailman/listinfo/kitten
