[Standards] Re: LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)

On Tue, 17 Dec 2024 at 14:57, Daniel Gultsch <daniel(a)gultsch.de> wrote: 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? 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).