Editor here. This is technically not a new last call. I just extended a last call that was already going on (by a couple of month :-) ) Marvin has incorporated some feedback from earlier in the last call and (personal opinion) it is probably ready now. The last call has been extended until just before what will probably be the next council meeting. cheers Daniel On Tue, Dec 17, 2024 at 3:56 PM Daniel Gultsch <daniel@gultsch.de> wrote:

This message constitutes notice of a Last Call for comments on XEP-0421.

Title: Anonymous unique occupant identifiers for MUCs Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users.

URL: https://xmpp.org/extensions/xep-0421.html

This Last Call begins today and shall end at the close of business on 2025-01-06.

Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

2. Does the specification solve the problem stated in the introduction and requirements?

3. Do you plan to implement this specification in your code? If not, why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

Your feedback is appreciated!

On Tue, 17 Dec 2024 at 14:57, Daniel Gultsch <daniel@gultsch.de> wrote:

4. Do you have any security concerns related to this specification?

Yes. 4.1 says that occupant ids "SHOULD" be unique to that MUC room; that is, other rooms on the service "SHOULD NOT" use the same identifier for the same room. This is highly problematic, since if a user is open about their identity in the (example) C++ room, they may inadvertantly reveal their identity in the (example) Java room, causing them huge embarrassment. Why is this a SHOULD?

5. Is the specification accurate and clearly written?

Modulo the perennial problem of confusing "anonymous" with "pseudonymous", yes. Perhaps understandably, the security issue above results from pseudonymity, rather than anonymity. Also, I think a more pseudocode-ish suggestion for implementation might be useful, and that might also result in a simpler suggestion: You have (roughly) HMAC(room_secret, bare_jid) - sensible, but you can get a more efficient mechanism if you do: HMAC(server_secret, bare_jid || NUL || room_jid) - the limitation here is that destroying and recreating the room with the same jid will use the same occupant ids; the advantage is that it needs only a new global variable to hold a single secret, which is trivial in config. If your programming language doesn't like string concatenation with NUL, just use "/" instead. This might also avoid the SHOULD; assuming that was predicating on data storage needs or something. (Aside: it recommends HMAC with a suitably strong hash algorithm; astonishingly even MD5 is strong enough here - I wouldn't recommend changing the text, mind, but for those on this list, use whatever hash algorithm is easiest).