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

2024-05-17 Thread Kevin Smith
On 8 May 2024, at 10:20, Daniel Gultsch 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

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

2024-05-08 Thread Marvin W
Sorry, maybe I wasn't explicit enough. I didn't mean to not include it, just that it does not belong into the "Security Considerations" section, but instead belongs into the "Occupant ID generation" section. It's meant to be a core part of the protocol, not just something implementers should

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

2024-05-08 Thread Sam Whited
I strongly disagree that this does not belong in the security considerations. "anonymous" is not a formally provable security property. You and I may know that that means "don't take a SHA-1 and assume that it will be hard to guess", but as we see over and over and over again many people won't

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

2024-05-08 Thread Marvin W
On Wed, 2024-05-08 at 10:19 -0400, Sam Whited wrote: > I'd like to see the security considerations expanded on this. > > In particular, in the business rules it mentions the fact that if > occupant-id isn't supported it could be spoofed. This should exist in > the security considerations. Fair.

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

2024-05-08 Thread Sam Whited
Indeed, sorry to be unclear, I'm suggesting that we should discuss this in the security considerations section (probably detailing exactly what "The occupant identifier MUST be generated such that it is anonymous" actually means in terms of security properties). In addition, I think we should

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

2024-05-08 Thread Stephen Paul Weber
Also, I suspect the naive way to implement this will be to hash the bare JID. We probably want to mention that this is a bad idea and that these identifiers should be random (or we should explicitly define the security properties that are required if they're derived, which probably includes

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

2024-05-08 Thread Sam Whited
I'd like to see the security considerations expanded on this. In particular, in the business rules it mentions the fact that if occupant-id isn't supported it could be spoofed. This should exist in the security considerations. Also, I suspect the naive way to implement this will be to hash