Re: [Standards] XEP-0045 1.25rc10 comments

[Peter Saint-Andre]

On 1/25/12 4:04 PM, Peter Saint-Andre wrote:

>> It may make sense to extend 210 to (2)
>> and (3).
> 
> That's the path I took based on your feedback (however, I notice that I
> didn't add anything about status code 210 to the section on
> user-requested nick changes, which is another time when the service
> might modify the user's nick).

Actually there is an example of that and some associated text, but I
didn't see it on a quick review.

Peter

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

Re: [Standards] XEP-0045 1.25rc10 comments

[Peter Saint-Andre]

Waqas, thanks for your feedback. Comments at end.

On 1/25/12 2:51 PM, Waqas Hussain wrote:
> On Wed, Jan 25, 2012 at 2:26 AM, Peter Saint-Andre  wrote:
>> On 1/24/12 11:14 AM, Peter Saint-Andre wrote:
>>
>> After jabbering with Kev for a bit, here's a follow-up on the status
>> code 210 issue (originally raised by Waqas Hussain).
>>
>> "If the user's nickname is modified by the service as a result of
>> registration and the user is in the room, the service SHOULD include
>> status code "210" in the updated presence notification that it sends
>> to all users." - this is new, I think, couldn't it break things? ***
>
> In what way does that break things?

 Prior to this change, 210 could only be received on 'your own'
 stanzas, so it's been reasonable for clients/libs to assume any time
 it sees 210 it's receiving its own stanza (and, given that servers
 tend to only send one status code at a time (to work around buggy
 clients), this is probably a sensible thing to do). If clients start
 receiving 210 from other people, I think it's entirely likely that
 things will break.
>>>
>>> But we have a separate status code (110) for self-presence.
>>
>> First, I found the original message from Waqas:
>>
>> http://mail.jabber.org/pipermail/standards/2011-September/025183.html
>>
>> He wrote:
>>
>> ###
>>
>> 3. Service changing room nick
>>
>> I'd like some text stating that a service can change the occupant's
>> nick at any time, including room join. An occupant MUST listen for
>> status code=100 in available presence for their current nick.
>>
>> ###
>>
>> I think Waqas meant that the client needs to listen for status code
>> "110" (self-presence) plus "210" (nick changed) but I'm not sure. Waqas,
>> please confirm.
>>
>> Via IM, Kev pointed out that this should be for self-presence only. I
>> think he's right about that, so one of the paragraphs currently in the
>> working version is wrong (right after Example 76):
>>
>>  If the user's nickname is modified by the service as a result of
>>  registration and the user is in the room, the service SHOULD include
>>  status code "210" in the updated presence notification that it sends
>>  to all users.
>>
>> I think the other instances are correct (after Examples 23 and 50
>> respectively):
>>
>>   If the user has connected using a MUC client (as indicated on
>>   joining the room by inclusino of the MUC extension), then the
>>   service MUST include a status code of "210" in the presence
>>   broadcast that it sends to the new occupant.
>>
>> and:
>>
>>   If the service modifies the user's nickname in accordance with local
>>   service policies, it MUST include a MUC status code of 210 in the
>>   presence stanza sent to the user. An example follows (here the
>>   service changes the nickname to all lowercase).
>>
>> See Example 51:
>>
>> Example 51. Occupant Changes Nickname, Modified by Service
>>
>> >from='ha...@shakespeare.lit/pda'
>>id='nx6z2v5'
>>to='co...@chat.shakespeare.lit/OldHag'/>
>>
>> >from='co...@chat.shakespeare.lit/oldhag'
>>id='D0E2B666-3373-42C9-B726-D52C40A48383'
>>to='ha...@shakespeare.lit/pda'>
>>  
>>>  jid='ha...@shakespeare.lit/pda'
>>  role='participant'/>
>>
>>
>>  
>> 
>>
>> So I propose that we fix the text after Example 76:
>>
>> OLD
>>  If the user's nickname is modified by the service as a result of
>>  registration and the user is in the room, the service SHOULD include
>>  status code "210" in the updated presence notification that it sends
>>  to all users.
>>
>> NEW
>>  If the user's nickname is modified by the service as a result of
>>  registration and the user is in the room, the service SHOULD include
>>  status code "210" in the updated presence notification that it sends
>>  to the user.
>>
>> Now, Kev raised another issue, which is that some clients don't properly
>> handle presence updates with more than one status code (e.g., they might
>> read only the first status code). My reply to that is: fix your client
>> or file a bug report.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
> 
> Yes, I did mean 110, not 100. There are three cases in which a service
> might rewrite a nick:
> 
> 1. on room join (status codes 110 and 210)
> 2. on user initiating a nick change (status codes 110 and 303)
> 3. at some point after join, without the user requesting a normal nick
> change (e.g., after nick registration, or service policy change)

I have another use case here, but that's not essential to this
discussion (suffice it to say that nicks might change after joining but
without the user requesting a nick change).

> I don't think (1) and (2) really need any extra status codes than what
> get sent normally, while (3) can be treated exactly like (2), as if
> the user requested the change. 

Yes, I think that's reasonable. At least, that is how I interpreted your
original comments. :)

> It may make sense to 

Re: [Standards] XEP-0045 1.25rc10 comments

[Waqas Hussain]

On Wed, Jan 25, 2012 at 2:26 AM, Peter Saint-Andre  wrote:
> On 1/24/12 11:14 AM, Peter Saint-Andre wrote:
>
> After jabbering with Kev for a bit, here's a follow-up on the status
> code 210 issue (originally raised by Waqas Hussain).
>
> "If the user's nickname is modified by the service as a result of
> registration and the user is in the room, the service SHOULD include
> status code "210" in the updated presence notification that it sends
> to all users." - this is new, I think, couldn't it break things? ***

 In what way does that break things?
>>>
>>> Prior to this change, 210 could only be received on 'your own'
>>> stanzas, so it's been reasonable for clients/libs to assume any time
>>> it sees 210 it's receiving its own stanza (and, given that servers
>>> tend to only send one status code at a time (to work around buggy
>>> clients), this is probably a sensible thing to do). If clients start
>>> receiving 210 from other people, I think it's entirely likely that
>>> things will break.
>>
>> But we have a separate status code (110) for self-presence.
>
> First, I found the original message from Waqas:
>
> http://mail.jabber.org/pipermail/standards/2011-September/025183.html
>
> He wrote:
>
> ###
>
> 3. Service changing room nick
>
> I'd like some text stating that a service can change the occupant's
> nick at any time, including room join. An occupant MUST listen for
> status code=100 in available presence for their current nick.
>
> ###
>
> I think Waqas meant that the client needs to listen for status code
> "110" (self-presence) plus "210" (nick changed) but I'm not sure. Waqas,
> please confirm.
>
> Via IM, Kev pointed out that this should be for self-presence only. I
> think he's right about that, so one of the paragraphs currently in the
> working version is wrong (right after Example 76):
>
>  If the user's nickname is modified by the service as a result of
>  registration and the user is in the room, the service SHOULD include
>  status code "210" in the updated presence notification that it sends
>  to all users.
>
> I think the other instances are correct (after Examples 23 and 50
> respectively):
>
>   If the user has connected using a MUC client (as indicated on
>   joining the room by inclusino of the MUC extension), then the
>   service MUST include a status code of "210" in the presence
>   broadcast that it sends to the new occupant.
>
> and:
>
>   If the service modifies the user's nickname in accordance with local
>   service policies, it MUST include a MUC status code of 210 in the
>   presence stanza sent to the user. An example follows (here the
>   service changes the nickname to all lowercase).
>
> See Example 51:
>
> Example 51. Occupant Changes Nickname, Modified by Service
>
>     from='ha...@shakespeare.lit/pda'
>    id='nx6z2v5'
>    to='co...@chat.shakespeare.lit/OldHag'/>
>
>     from='co...@chat.shakespeare.lit/oldhag'
>    id='D0E2B666-3373-42C9-B726-D52C40A48383'
>    to='ha...@shakespeare.lit/pda'>
>  
>              jid='ha...@shakespeare.lit/pda'
>          role='participant'/>
>    
>    
>  
> 
>
> So I propose that we fix the text after Example 76:
>
> OLD
>  If the user's nickname is modified by the service as a result of
>  registration and the user is in the room, the service SHOULD include
>  status code "210" in the updated presence notification that it sends
>  to all users.
>
> NEW
>  If the user's nickname is modified by the service as a result of
>  registration and the user is in the room, the service SHOULD include
>  status code "210" in the updated presence notification that it sends
>  to the user.
>
> Now, Kev raised another issue, which is that some clients don't properly
> handle presence updates with more than one status code (e.g., they might
> read only the first status code). My reply to that is: fix your client
> or file a bug report.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

Yes, I did mean 110, not 100. There are three cases in which a service
might rewrite a nick:

1. on room join (status codes 110 and 210)
2. on user initiating a nick change (status codes 110 and 303)
3. at some point after join, without the user requesting a normal nick
change (e.g., after nick registration, or service policy change)

I don't think (1) and (2) really need any extra status codes than what
get sent normally, while (3) can be treated exactly like (2), as if
the user requested the change. It may make sense to extend 210 to (2)
and (3).

The question is, how should clients use these status codes? In my
opinion, simply assuming your current nick is the last one with a 110
works in all cases for maintaining internal client state, while 303
and 210 could be used to generate user notifications if required about
server modification of nick.

--
Waqas Hussain

[Standards] UPDATED: XEP-0114 (Jabber Component Protocol)

[XMPP Extensions Editor]

Version 1.6 of XEP-0114 (Jabber Component Protocol) has been released.

Abstract: This specification documents the existing protocol used for 
communication between servers and "external" components over the Jabber network.

Changelog: [See revision history] (psa)

Diff: http://xmpp.org/extensions/diff/api/xep/0114/diff/1.5/vs/1.6

URL: http://xmpp.org/extensions/xep-0114.html

[Standards] UPDATED: XEP-0114 (Jabber Component Protocol)

[XMPP Extensions Editor]

Version 1.6 of XEP-0114 (Jabber Component Protocol) has been released.

Abstract: This specification documents the existing protocol used for 
communication between servers and "external" components over the Jabber network.

Changelog: [See revision history] (psa)

Diff: http://xmpp.org/extensions/diff/api/xep/0114/diff/1.5/vs/1.6

URL: http://xmpp.org/extensions/xep-0114.html

[Standards] UPDATED: XEP-0077 (In-Band Registration)

[XMPP Extensions Editor]

Version 2.4 of XEP-0077 (In-Band Registration) has been released.

Abstract: This specification defines an XMPP protocol extension for in-band 
registration with XMPP-based instant messaging servers and other services 
hosted on an XMPP network (such as groupchat rooms and gateways to non-XMPP IM 
services). The protocol is extensible via use of data forms, thus enabling 
services to gather a wide range of information during the registration process. 
The protocol also supports in-band password changes and cancellation of an 
existing registration.

Changelog: Defined service discovery support. (psa)

Diff: http://xmpp.org/extensions/diff/api/xep/0077/diff/2.3/vs/2.4

URL: http://xmpp.org/extensions/xep-0077.html

Re: [Standards] Proposed XMPP Extension: The 'xmpp.pubsub' URI Scheme

[Ralph Meijer]

On 2012-01-24 01:03, XMPP Extensions Editor wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: The 'xmpp.pubsub' URI Scheme

Abstract: This document defines the format of Uniform Resource Identifiers
 (URIs) to identify nodes in the context of Publish-Subscribe services as
 well as items within the scope of such nodes.

URL: http://xmpp.org/extensions/inbox/pubsub-uri.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an offi


In the meeting just now, several people voiced their concerns. Mine is:

What does this provide over 
?


--
ralphm

Re: [Standards] Security Question with

[Dave Cridland]

On Wed Jan 25 04:41:29 2012, Evgeniy Khramtsov wrote:

On 25.01.2012 09:30, Mike Wacker wrote:

I saw this in RFC 6120:

"To reduce the possibility of a denial-of-service attack, (a) the  
receiving entity SHOULD NOT close the stream with a  
 stream error until after the confidentiality and  
integrity of the stream have been protected via TLS or an  
equivalent security layer (such as the SASL GSSAPI mechanism), and  
(b) the receiving entity MAY have a policy of following redirects  
only if it has authenticated the receiving entity. In addition,  
the initiating entity SHOULD abort the connection attempt after a  
certain number of successive redirects (e.g., at least 2 but no  
more than 5)."


Does anyone have any clarification to this section and the  
specific DoS threat if TLS (or authentication) does not happen  
before ?




Indeed, what problem could occur with unauthenticated redirections?


I thought only Brits were allowed to do sarcasm?

There's one DoS and a general attack:

1) General attack is to spoof the TCP response and redirect to a  
server of your choice. Note that TLS prevents the TCP stream  
spoofing; authentication also prevents DNS spoofing. This accounts  
for the SHOULD NOT and the MAY.


2) Specific DoS is to setup a loop of servers redirecting to each  
other. You'd likely spoof into the loop. This would cause a  
continuous connection loop. This accounts for the final SHOULD.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Security Question with

[Mike Wacker]

On 1/24/2012 8:41 PM, Evgeniy Khramtsov wrote:

On 25.01.2012 09:30, Mike Wacker wrote:

I saw this in RFC 6120:

"To reduce the possibility of a denial-of-service attack, (a) the 
receiving entity SHOULD NOT close the stream with a  
stream error until after the confidentiality and integrity of the 
stream have been protected via TLS or an equivalent security layer 
(such as the SASL GSSAPI mechanism), and (b) the receiving entity MAY 
have a policy of following redirects only if it has authenticated the 
receiving entity. In addition, the initiating entity SHOULD abort the 
connection attempt after a certain number of successive redirects 
(e.g., at least 2 but no more than 5)."


Does anyone have any clarification to this section and the specific 
DoS threat if TLS (or authentication) does not happen before 
?




Indeed, what problem could occur with unauthenticated redirections?

I see, then it would be moreso a tampering threat than a DoS threat, no? 
So basically, I want to know that the server I'm connecting to is 
legitimate and that my connection is secure before I trust the contents 
of that redirect from the server.


Also, is there a typo in (b), it sounds like it should read "(b) the 
*initiating* entity MAY have a policy of following redirects only if it 
has authenticated the receiving entity"