8 May
2024
8 May
'24
3:20 a.m.
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 reconnects and renames. It thus prevents
impersonification of anonymous users.
URL: https://xmpp.org/extensions/xep-0421.html
This Last Call begins today and shall end at the close of business on
2024-05-27.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
8 May
8 May
8:19 a.m.
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 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).
—Sam
On 2024-05-08 05: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 reconnects and renames. It thus prevents
impersonification of anonymous users.
URL: https://xmpp.org/extensions/xep-0421.html
This Last Call begins today and shall end at the close of business on
2024-05-27.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
--
Sam Whited
sam(a)samwhited.com
8:22 a.m.
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).
The XEP suggests "One way to ensure these properties is to generate a
private secret key for every room and use an HMAC algorithm with a
sufficiently secure hash function to generate the occupant identifier from
the real bare JID and that secret key."
8:26 a.m.
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 mention the naive use case that people may think is also fine
(just doing a hash of the bare JID) and be explicit that this is not
good instead of just passively assuming this is covered and understood
by the word "anonymous".
—Sam
P.S. re-sending something I accidentally sent off-list, sorry for the
duplicate Stephen.
On 2024-05-08 10:22, Stephen Paul Weber wrote:
--
Sam Whited
sam(a)samwhited.com
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).
The XEP suggests "One way to ensure these properties is to generate a
private secret key for every room and use an HMAC algorithm with a
sufficiently secure hash function to generate the occupant identifier
from the real bare JID and that secret key."
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org 
8:29 a.m.
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
8:41 a.m.
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:
--
Sam Whited
sam(a)samwhited.com
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
8:58 a.m.
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:
--
Sam Whited
sam(a)samwhited.com
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org 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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org 
17 May
17 May
5:16 a.m.
New subject: LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)
On 8 May 2024, at 10:20, Daniel Gultsch <daniel(a)gultsch.de> 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 reconnects and renames. It thus prevents
impersonification of anonymous users.
URL: https://xmpp.org/extensions/xep-0421.html
This Last Call begins today and shall end at the close of business on
2024-05-27.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Being lazy with responses, but seems fine to me, I expect we’ll implement eventually.
/K
114
days inactive
123
days old
7 comments
5 participants
participants (5)
-
Daniel Gultsch -
Kevin Smith -
Marvin W -
Sam Whited -
Stephen Paul Weber