Subject: [xmpp] #77: returning stanzas for non-existent users

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 02:54:38 -0000

#77: returning stanzas for non-existent users
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Section 13.11 (Directory Harvesting) states:

 > When a server generates an error stanza in response to receiving
 > a stanza for a user account that does not exist, the use of the
 > <service-unavailable/> stanza error condition can help protect
 > against dictionary attacks, since this is the same error
 > condition that is returned if, for instance, the namespace of
 > an IQ child element is not understood, or if offline message
 > storage or message forwarding is not enabled for a domain.

 Matthew Wild commented: "Does it make sense to always return <service-
 unavailable/> for <message/> (?) stanzas to a non-existent user account?
 Since they wouldn't be returned if the user account existed, unless the
 server was configured to bounce messages from unsubscribed users."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/77>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jun 2010 20:57:09 -0600

> #77: returning stanzas for non-existent users

Matthew, this text is not saying that a server MUST return
<service-unavailable/> in all instances, only that *if* that error
condition is returned (instead of some more revealing error condition,
such as <item-not-found/>) then a would-be attacker is prevented from
launching a directory harvesting attack.

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 04:20:59 -0000

#77: returning stanzas for non-existent users
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/77#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Matthew Wild <[email-masked]>
Date: Fri, 25 Jun 2010 12:30:52 +0100

On 22 June 2010 03:57, Peter Saint-Andre <[email-masked]> wrote:
>>  > When a server generates an error stanza in response to receiving
>>  > a stanza for a user account that does not exist, the use of the
>>  > <service-unavailable/> stanza error condition can help protect
>>  > against dictionary attacks, since this is the same error
>>  > condition that is returned if, for instance, the namespace of
>>  > an IQ child element is not understood, or if offline message
>>  > storage or message forwarding is not enabled for a domain.
>>

I perhaps didn't make my original point as clearly as I could have...

By directory harvesting I'm assuming you mean an attacker sending
stanzas to JIDs, and studying the responses received from those JIDs.
In most servers I know, sending a message to a non-existent user will
bounce an error (service-unavailable, as the text recommends) but if
the user exists the message is stored offline. This signals to the
attacker whether an account exists.

I agree there is probably nothing wrong with this text,
service-unavailable is a good generic error to return. But it may want
to be additionally noted that a server may want to exercise caution in
returning any error at all to avoid this information leak.

Matthew

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jun 2010 12:42:53 +0100

> returning any error at all to avoid this information leak.

I concur.

Non-existent users SHOULD behave as though they are simply users who  
don't want to talk to you.

However, as discussed in jdev, this is a complex area with no likely  
perfect solution:

[12:34:53] dwd: MattJ, Damn, have to make my directory harvester use  
<presence type='subscribe'/> now.
[12:35:18] MattJ: Silently swallow that too?
[12:35:20] petermount: hehe, just read the email [12:35:46] dwd:  
MattJ, Spec says to immediately reply with an unsubscribed, no?
[12:35:52] MattJ: I thought that was optional :/
[12:35:59] dwd: MattJ, Ah, could be.
[12:36:04] Kev: I think that's required.
[12:36:07] Kev: I could be wrong.
[12:36:12] MattJ: I'm likely wrong
[12:36:14] petermount: that sounds right to me
[12:36:38] dwd: MattJ, Either way, I agree - users who don't exist  
should behave like users who are unresponsively not interested in  
talking back.
[12:37:18] MattJ: No such user: "For a presence stanza of type  
"subscribe", the server MUST return a presence stanza of type  
"unsubscribed"."
[12:37:29] MattJ: (3921bis)
[12:37:30] dwd: MattJ, But I'd bet I could build a director harvester  
that worked whatever, eventually.
[12:37:37] MattJ: Yes, I'm sure too
[12:37:59] MattJ: Post back to the thread :)
[12:38:01] dwd: MattJ, I suppose one option would be to respond with  
service-unavailable even if we do store a message to offline.
[12:38:10] MattJ: That would be Wrong.
[12:38:23] dwd: Would it?
[12:38:26] Kev: Yes.
[12:38:49] dwd: We haven't delivered the message, we have no way of  
knowing when the message may be delivered or if it ever will be.
[12:38:55] Kev: Error: Success.
[12:39:20] dwd: Still, though, that replaces a harvester attack with  
a presence leak.
[12:40:22] petermount: I wonder if theres a case of server side only  
storing messages from people in someones roster, then if not then  
respond service-unavailable.
[12:40:38] dwd: petermount, That's certainly been proposed before.
[12:40:40] petermount: ok that would be server dependent, but then at  
least the sender would know it wasn't delivered
[12:41:12] Kev: But that's not quite right either.
[12:41:22] Kev: Well, it's very not right.
[12:41:41] Kev: You shouldn't need to be in someone's roster to be  
able to talk to them.
[12:41:51] Kev: Some deployments may choose to add that requirement,  
but it shouldn't be mandatory.

The debate rages on. Well, chatters on.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Mount <[email-masked]>
Date: Fri, 25 Jun 2010 13:04:03 +0100

On Fri, Jun 25, 2010 at 12:42 PM, Dave Cridland <[email-masked]> wrote:

> Non-existent users SHOULD behave as though they are simply users who don't
> want to talk to you.
>
> [12:35:20] petermount: hehe, just read the email [12:35:46] dwd: MattJ,
> Spec says to immediately reply with an unsubscribed, no?
> [12:36:38] dwd: MattJ, Either way, I agree - users who don't exist should
> behave like users who are unresponsively not interested in talking back.
> [12:37:18] MattJ: No such user: "For a presence stanza of type "subscribe",
> the server MUST return a presence stanza of type "unsubscribed"."
> [12:37:30] dwd: MattJ, But I'd bet I could build a director harvester that
> worked whatever, eventually.
> [12:38:49] dwd: We haven't delivered the message, we have no way of knowing
> when the message may be delivered or if it ever will be.
> [12:39:20] dwd: Still, though, that replaces a harvester attack with a
> presence leak.
> storing messages from people in someones roster, then if not then respond
> service-unavailable.
> [12:40:40] petermount: ok that would be server dependent, but then at least
> the sender would know it wasn't delivered
> [12:41:41] Kev: You shouldn't need to be in someone's roster to be able to
> talk to them.
> [12:41:51] Kev: Some deployments may choose to add that requirement, but it
> shouldn't be mandatory.
>

Just to add what was said just after this before jdev went quiet again :-)

(12:42:45) petermount: i wan't saying mandatory, but as a server option... I
could see some deployments choosing that, or an individual choosing that.
(12:42:54) Kev: Yes, I think that's entirely valid.
(12:43:34) petermount: although then there's a choice, so if you choose to
accept all messages then you know you may have the harvester issue...
(12:43:55) petermount: but then at least that issue is then known about
rather than someone saying later on of a 'security' hole which really isn't
(12:44:29) dwd: petermount, Making it a per-user option or a per-server one?
(12:47:18) petermount: dwd: I think either - give the user a choice and/or
the server admin may also enforce it

Peter

-- 
Peter Mount

Email: [email-masked]
 Web:  http://retep.org
Phone: +44 (0)7903 155887
XMPP: [email-masked] (Primary)
XMPP: [email-masked] (blackberry)

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 13:26:02 -0600

> don't want to talk to you.

That makes sense. Text adjusted as follows:

###

13.11.  Directory Harvesting

   If a server generates an error stanza in response to receiving a
   stanza for a user account that does not exist, using the <service-
   unavailable/> stanza error condition can help protect against
   directory harvesting attacks, since this is the same error condition
   that is returned if, for instance, the namespace of an IQ child
   element is not understood, or if offline message storage or message
   forwarding is not enabled for a domain.  However, subtle differences
   in the exact XML of error stanzas, as well as in the timing with
   which such errors are returned, can enable an attacker to determine
   the network presence of a user when more advanced blocking
   technologies are not used (see for instance [XEP-0016] and
   [XEP-0191]).  Therefore, a server that exercises a higher level of
   caution might not return any error at all in response to certain
   kinds of received stanzas, so that a non-existent user appears to
   behave like a user that has no interest in conversing with the
   sender.

###

> However, as discussed in jdev, this is a complex area with no likely

Indeed. Utopia is not an option. :)

Peter

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