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-le...@xmpp.org > > -- > Sam Whited > s...@samwhited.com > _______________________________________________ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
