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 consider if they care about security. Marvin On Wed, 2024-05-08 at 10:41 -0400, Sam Whited wrote:
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 (I should start keeping an "X days since I saw a breach due to a website using a naive hash" sign at my desk; it wouldn't get very high).
This seems like a common enough misunderstanding of a complicated topic that I think we should explicitly call it out as the way this is most likely to fail. I can't see that being more explicit could hurt in any way, and if there's a bad thing that defeats the entire purpose of the XEP and is likely to happen, it seems worth calling out.
—Sam
On 2024-05-08 10:29, Marvin W wrote:
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.
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 using a salt and ensuring high entropy).
This is not only a bad idea, but is very much non-compliant: "The occupant identifier MUST be generated such that it is anonymous. This means that it MUST be sufficiently hard to determine the real bare JID of an occupant from its occupant identifier. Additionally, a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service."
Nonetheless could be made even more specific that this is not allowed (aka MUST NOT just hash using widely known, static parameters). However, I think this does not belong into Security Considerations, as not complying is not just "bad for security", but actually defeats the whole purpose of the XEP.
Marvin _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
-- Sam Whited sam@samwhited.com _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org