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(a)gultsch.de> wrote:

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