Re: [xmpp] Followup WGLC of draft-ietf-xmpp-3921bis-12

[Peter Saint-Andre <[e-mail]>]

On 9/9/10 6:50 PM, Matthew Wild wrote:

>>> 2.3.3: It's an error to supply duplicate groups for a contact, but
>>> the spec doesn't mandate a particular method for group name
>>> comparison, meaning there is no way for a client to know it is
>>> submitting duplicate groups without testing and receiving the error.
>>
>> Correct. Given that string comparison methods are in flux (cf. PRECIS
>> WG), I don't know if we want to make a hard requirement about the one
>> true method to use. In particular, introducing a normative dependency on
>> stringprep (via the Resourceprep profile from XMPP-ADDR) means we'll
>> need to track changes to that spec (it should be obsoleted in the next
>> year or two if the PRECIS work completes successfully).
>>
>>> Even if the client did this, it would not be able to tell which the
>>> offending group(s) in the request are.
>>
>> Also true.
>>
>> How problematic do you think this is? Here is how I see it:
>>
>> 1. It's relatively rare for a contact to be in more than one group.
>>
>> 2. Duplicates are easy to detect for ASCII, but more difficult to detect
>> for full Unicode (e.g., Folks with an "oh" vs. Fοlks with an omicron --
>> these are confusable but wouldn't be caught by something like Resourceprep).
>>
>> 3. There's no serious *interoperability* issue here because the client
>> can simply remove one of the groups, change one of the group names, etc.
>>
>> It seems fine if we leave this up to the implementation, but if folks
>> think otherwise then we need to have a discussion.
>>
> 
> Given the obvious difficulties in solving this for now, I don't
> consider it a major issue.

That's how I see it for now, but others might disagree.

>>> 2.3.3: I'm still of the opinion that one shouldn't be able to add
>>> one's own JID to one's roster - but I guess I missed the conclusion
>>> on this discussion, I can live with it if we're settled on it.
>>
>> I think the objection was "special casing is bad", and given your
>> previous arguments using that reasoning I couldn't disagree. :)
>>
> 
> Ah yes, special casing is very bad :)
> 
> And this is exactly the problem. In XMPP you already have an implicit
> subscription to your own account - the server will send you presence
> for your resources, and you are a trusted entity, etc.
> 
> If we are to allow having yourself in your roster, it means that to
> behave sensibly you would have to add checks to see if the current JID
> being processed (as part of a presence/PEP broadcast for example) is
> the JID of the roster's owner - thus the special casing.
> 
> I don't think it's a major issue, just something I'm not particularly fond of.

And neither am I -- IMHO adding yourself to your own roster is dumb,
useless, and unnecessary. But I don't see any active harm in it, either...

>>> 3.2.2: After processing the unsubscribed, the spec says that a
>>> server MUST send unavailable presence from all the user's resources.
>>> This would constitute a presence leak if the user was not already in
>>> the roster with a subscription of "from" or "both".
>>
>> Hmm. If the contact's server sends presence of type unavailable from the
>> bare JID then this problem goes away. That seems like the right behavior
>> here anyway (because at this point the user is officially unsubscribed).
>>
> 
> Agreed - though I don't think presence from bare JID was defined in
> 392x originally, so this could conceivably cause interop issues with
> older clients/servers.

Another option: the contact's server could send the "unavailable"
notifications (from all full JIDs) before sending the "unsubscribed" --
that seems preferable because the user is still subscribed to the
contact when the unavailable notifications are sent, then the contact's
server sends the "unsubscribed" as the coup de grace. :)

>>> 4.7.1: Conflicts with 4.3, which says clients MAY send probes - here
>>> it says SHOULD NOT.
>>
>> I think SHOULD NOT is correct and propose the following fix to 4.3:
>>
>>      Implementation Note: Presence probes SHOULD NOT be sent by a
>>      client because in general a client will not need to send them,
>>      since the task of gathering presence from a user's contacts is
>>      managed by the user's server.
>>
> 
> Seems fine to me (though I'm not primarily a client developer).

Yes, we'll ping some of them to see what they think. :)

>>> 8.5.3.2.1: I don't think there should be an easy option of silently
>>> ignoring type="groupchat" to a non-existent resource, the error
>>> reply is used to detect MUC ghosts quickly, and this should at least
>>> be mentioned.
>>
>> Isn't that a matter for XEP-0045? See below.
>>
>>> 8.5.4: Table 1: I think the bare and full responses of type
>>> 'groupchat' are switched in all rows. According to the text, bare
>>> should be S/E, and though it says in the text that full for groupchat
>>> should be S/E too, I think that should be changed to prevent the
>>> possibility of MUC ghosts (see 8.5.3.2.1 above).
>>
>> I used groupchat messages to illustrate the stanza processing rules in
>> the "dissertation on message delivery" that I sent at the end of July:
>>
>> http://www.ietf.org/mail-archive/web/xmpp/current/msg01557.html
>>
>> To quote:
>>
>> ###
>>
>> Take groupchat messages as a fairly non-controversial example. Clearly
>> we want to deliver such messages to the user who has joined a groupchat
>> room. However, if the user who was in a room then went offline, it's
>> helpful to return an error to the chat service so that it can clean up
>> any "ghosts" in the room. On the other hand, it's dangerous to return an
>> error if the user doesn't exist when the same kind of message sent to an
>> existing account would not return an error (because that would enable a
>> directory harvesting attack).
>>
>> One simple message handling rule that would meet all of the foregoing
>> criteria is "the server always returns an error in response to messages
>> of type groupchat sent to bare JIDs".
>>
>> However, handling of groupchat messages sent to full JIDs is a bit more
>> complex. If the server delivers the message when there is an active
>> resource that matches the full JID but returns an error when there is no
>> matching full JID, then an attacker could send lots of messages to the
>> same account with various random resources and perhaps discover whether
>> the user is online. Whether the attack is practical is another matter --
>> the server could start to return a different error condition if it
>> detects such an attack from a particular JID, although the attacker
>> could be smart and send its messages from multiple JIDs. We need to
>> weigh costs and benefits, and recognize that there are legitimate
>> tradeoffs between functionality and security. IMHO it is more difficult
>> to figure out what the right tradeoffs are with respect to presence
>> leaks than directory harvesting attacks, which is one reason why I think
>> we're having trouble agreeing on the right behavior in the case of a
>> headline message that is sent to a full JID where no such resource is
>> online.
>>
>> ###
>>
>>> Table 1: For type "headline", I believe the table defines sensible
>>> handling rules, but it is at odds with the text which says S/E.
>>
>> I disagree -- see the reasoning above. I agree that we might want to
>> define this more completely in XEP-0045.
>>
> 
> Ok, that's fine - but the table is still at odds with the text in
> these cases, no?

Let's roll the videotape...

Section 8.5.2.1.1 (which defines the delivery rule for messages sent to
a bare JID when available resources exist) has this:

   For a message stanza of type "groupchat", the server MUST NOT deliver
   the stanza to any of the available resources but instead MUST return
   a stanza error to the sender, which SHOULD be <service-unavailable/>.

Section 8.5.2.2.1 (same, but no available resources) has:

   For a message stanza of type "groupchat", the server MUST return an
   error to the sender, which SHOULD be <service-unavailable/>.

Section 8.5.3.1 (full JID, resource matches) has:

   o  For a message stanza, the server MUST deliver the stanza to the
      resource.

Section 8.5.3.2 (full JID, no resource matches) has:

   For a message stanza of type "normal", "groupchat", or "headline",
   the server MUST either (a) silently ignore the stanza or (b) return
   an error stanza to the sender, which SHOULD be <service-
   unavailable/>.

The relevant parts of the table from Section 8.5.4 are as follows...

   Table 1: Message Delivery Rules

   +--------------------------------+
   | Condition        |  Groupchat  |
   +--------------------------------+
   | ACCOUNT DOES NOT EXIST         |
   |  bare            |      E      |
   |  full            |     S/E     |
   +--------------------------------+
   | ACCOUNT EXISTS, BUT NO ACTIVE  |
   | RESOURCES                      |
   |  bare            |      E      |
   |  full (no match) |     S/E     |
   +--------------------------------+
   | 1+ NEGATIVE RESOURCES BUT ZERO |
   | NON-NEGATIVE RESOURCES         |
   |  bare            |      E      |
   |  full match      |      D      |
   |  full no match   |     S/E     |
   +--------------------------------+
   | 1 NON-NEGATIVE RESOURCE        |
   |  bare            |      E      |
   |  full match      |      D      |
   |  full no match   |     S/E     |
   +--------------------------------+
   | 1+ NON-NEGATIVE RESOURCES      |
   |  bare            |      E      |
   |  full match      |      D      |
   |  full no match   |     S/E     |
   +--------------------------------+

The text and the table seem consistent to me, and also preserving of the
privacy and security principles laid out in the "dissertation" I sent on
July 31 (and incorporated into the draft soon thereafter).

>>> A.2.4: Question marks after "cancel pre-approval" - intentional?
>>> Cancelling pre-approvals is mentioned in the text in 3.2.1, though I
>>> think it would be helpful to mention it briefly in 3.4 also.
>>
>> It's described in the implementation note at the end of Section 3.4.2:
>>
>>      Implementation Note: A client can cancel a pre-approval by sending
>>      a presence stanza of type "unsubscribed", as described more fully
>>      under Section 3.2.  In this case the user's server would send a
>>      roster push to all of the user's interested resources with the
>>      'approved' attribute removed.
>>
> 
> Thanks, I missed that - looks good. The question marks in the table
> are not intentional though, are they?

They were intentional (to indicate that processing the "unsubscribed"
might result in cancelling the pre-approval), but I've removed them
because there is no state change in that case. So now each of those
cells in the table has:

   |  no state change [1]  |

Where the footnote is:

      [1] This event can result in cancelling of a subscription pre-
      approval, as described under Section 3.4.

I note in passing that we're kind of dancing around the question of
whether adding or removing a subscription pre-approval is a state change
(on par with something like "None+Pending-Out"), but in the spec I'm
saying that they are not subscription state changes. That's my story and
I'm sticking to it. :)

/psa