Re: [Standards] XEP-0045 1.25rc7

[Peter Saint-Andre]

On 10/6/11 4:36 AM, Alexander Holler wrote:
 Am 05.10.2011 21:56, schrieb Mike Wacker:
 On 10/4/2011 11:15 AM, Alexander Holler wrote:
 If the server never times out a room that is created but not configured
 and unlocked, then an easy DOS vector is to flood the server with room
 creation requests but never configure any of the rooms. Since these
 unconfigured rooms never time out, these creation requests will
 eventually starve the server of resources. Throttling won't work here,
 as it will slow but not stop the eventual starvation.

 Two mitigations would be to either time-out unconfigured rooms or put a
 cap on the number of unconfigured rooms a single user can create. You
 could also have a max cap of total rooms for all users, but that also
 has DOS implications because even if malicious users can't DOS the
 server, they can DOS other users trying to create rooms if they can hit
 the server cap.

 Whats the difference between unconfigured and configured rooms?

 It's as easy to DOS a server with configured rooms as with
 unconfigured rooms and it will cost a malicious client almost nothing
 to configure a room along with the creation.

 Regards,

 Alexander
 Good call, Alexander, my initial line of inquiry began with the question
 of what if a malicious client intentionally did not configure the room,
 but configuring the room does not make the problem go away.

 In fact, configured rooms present additional complications. If a user
 sends an occasional message to each room after its unlocked, this would
 also with little cost to the hacker would prevent the server from timing
 out and destroying the room due to inactivity.

That's not an attack we've seen in the wild, as far as I know.

 The solution is simple, a (service global) limit for ownerships in rooms.

XEP-0045 doesn't cover service-global features. We've always said we
might write a spec about that, though.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] XEP-0045: Reserved Nicks and GC Compatibility

[Peter Saint-Andre]

On 10/5/11 2:11 PM, Mike Wacker wrote:
 On 10/4/2011 10:14 AM, Peter Saint-Andre wrote:
 On 10/3/11 5:11 PM, Mike Wacker wrote:
 Hello,

 One of the tenets of XEP-0045 is backwards-compatibility with groupchat
 1.0.
 Additional features do not necessarily introduce incompatibility. The
 old Groupchat 1.0 protocol had very few features.
 Yes, a feature, for example, to request a unique nick would not create
 an incompatibility since old clients wouldn't use the feature. If you
 still let the client use any nick, it's backwards-compatible.
 
 But if you locked down nicks and required the client to use the nick
 returned by the feature, you would impact a pre-existing scenario,
 entering a room.
 I was wondering if reserved nicks break this tenet. XEP-0045 says
 clients SHOULD first try to discover a reserved nick, if any, before
 entering a room. However, the server MAY lock down nicks and return an
 error if the reserved nick is not used. If it does lock down nicks, then
 the client actually MUST (not SHOULD) check for a reserved nick before
 entering the room, since using any other nick would cause an error.
 Rooms with nick lockdown are typically deployed in very controlled
 environments (e.g., military systems where each person must be
 identified exactly as they are registered or authenticated).
 Or an easy way to avoid dealing with nick conflicts. If you locked down
 nicks, you could also have a predetermined 1:1 mapping between nicks and
 bare jids that can be calculated either way with O(1) space. While there
 always expected use cases, I find it's generally not good to assume a
 feature would only be used in a certain way :)
 
 But since the server can rewrite nicks, is it safe to say the client
 MUST gracefully handle this scenario? The one area where that causes
 concern for me is existing groupchat 1.0 clients, I obviously do not
 know how they would handle a nick rewrite.
 
 I used the Wayback Machine to look at the old page about the groupchat
 1.0 protocol and early versions of JEP-0045, and none of them indicate
 support for discovering reserved nicks, meaning the client has to set
 the nick instead.
 Correct.

 Thus, it seems like older clients, including
 groupchat, would actually break if the server locked down nicks and
 returned an error if the reserved nick was not used to enter a room.
 So you couldn't join the room. Again, such rooms will be deployed in
 very controlled environments.

 (Though I don't know the history of groupchat other than what old docs
 said, so someone can correct me if there's some missing piece here not
 mentioned in the docs.)

 RC7 for XEP-0045 1.25 allows servers to rewrite nicks. If a nick rewrite
 does not break old groupchat clients, perhaps we should say the server
 MUST rewrite the nick instead of returning an error if the nicks are
 locked down and a nick other than the reserved one is used to enter the
 room.
 I do think that such an approach is more consistent with Postel's Law,
 so I'll adjust the text accordingly.

Thinking about this further, it strikes me that old groupchat 1.0
clients will not know anything about the 210 status code, so in that
case it would be better for the service to return an error. Note that
the service knows which clients support groupchat 1.0 and which clients
support MUC, so it can send an error to the former and a nick change to
the latter.

/psa