Subject: [xmpp] Stream from an unsupported hostname.

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 11:41:03 +0100

4.6.1.3
"If the initiating entity provides no 'to' attribute or provides an
   unknown host in the 'to' attribute and the error occurs during stream
   setup, the receiving entity SHOULD provide an authoritative hostname
   in the 'from' attribute of the stream header sent before termination,
   but absent such an authoritative hostname MAY instead simply populate
   the response stream's 'from' attribute with the value of the initial
   stream header's 'to' attribute (where the value of the 'from'
   attribute MAY be empty if the initiating entity provided no 'to'
   attribute)."

Why would you want to return a from for a hostname that you don't
service? If you know the hostname is wrong, it seems that either a
hostname that you support, or no hostname at all, is better than a
hostname that's wrong.

/K

---

From: Matthew Wild <[email-masked]>
Date: Mon, 7 Jun 2010 17:00:17 +0100

On 7 June 2010 11:41, Kevin Smith <[email-masked]> wrote:

> hostname that you support, or no hostname at all, is better than a

Since I was partially responsible for pushing this text I'll give some
rationale.

Some implementations currently handle this by replying from their
"default" host. Prosody doesn't have a default host, and there is no
other reason we need one (or force the user to specify one). Another
suggestion was to pick one host we do serve at random and use that - I
really think that's just a silly idea, imagine a mass hosting service
doing that for example :)

Other implementations use some other value, like the machine's actual
hostname. This I believe is quite wrong, an XMPP stream coming from
another XMPP entity that doesn't exist...?

So the alternative then for us was to not provide a from address,
which was against the spec, and not something I was comfortable with.
An attribute that is mandatory, but not sometimes? Doesn't feel right
to me.

An empty value is a possible solution to all this, but still I don't
prefer it over the existing text.

Why? The client initiated a stream to a virtual entity, and it only
makes sense for a reply stream to come from that same entity. Whether
the server likes it or not, the client believes that that server is
responsible for the given entity. That entity saying nothing but "I
don't exist" seems perfectly reasonable to me.

Regards,
Matthew

---

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 17:17:44 +0100

> Since I was partially responsible for pushing this text I'll give some

Ok, I buy that explanation, thanks.

> prefer it over the existing text.

I do, it seems to be the right fix here.

> don't exist" seems perfectly reasonable to me.

I think that, no matter how confused the client is, jabber.org
shouldn't be sending a stream claiming to be from microsoft.com.

/K

---

From: Jack Moffitt <[email-masked]>
Date: Mon, 7 Jun 2010 13:02:18 -0600

> I do, it seems to be the right fix here.
...
> shouldn't be sending a stream claiming to be from microsoft.com.

I'm with Kevin here.

jack.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 07 Jun 2010 20:41:38 +0100

> > shouldn't be sending a stream claiming to be from microsoft.com.

I've had a good long think, and can't think of any case where I want  
jabber.org to pretend to be microsoft.com to satisfy a confused  
client - "How come I get an error from microsoft.com saying  
microsoft.com no longer does XMPP?"

I also can't think of any case where we want it to admit to being  
jabber.org if the client thinks it's microsoft.com, either - that  
feels uncomfortably like revealing something the client has no good  
reason to know.

I do like the idea of an empty string, it feels conceptually like the  
root DN in LDAP. (In turn suggesting we might use it for other  
special things where the client cannot know the domain name yet, or  
where the XMPP service has no domain name).

Dave.
-- 
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 Saint-Andre <[email-masked]>
Date: Mon, 07 Jun 2010 15:37:53 -0600

>> > shouldn't be sending a stream claiming to be from microsoft.com.

That I agree with.

> jabber.org to pretend to be microsoft.com to satisfy a confused client -
> "How come I get an error from microsoft.com saying microsoft.com no
> longer does XMPP?"
> 
> jabber.org if the client thinks it's microsoft.com, either 

Common courtesy?

"Hey, this is jabber.org, not microsoft.com!"

> - that feels
> uncomfortably like revealing something the client has no good reason to
> know.

What's the attack here? Randomly connecting to IP addresses to figure
out what the authoritative hostname is at each address?

> root DN in LDAP. (In turn suggesting we might use it for other special
> things where the client cannot know the domain name yet, or where the
> XMPP service has no domain name).

How about this text?

   If the initiating entity provides no 'to' attribute or provides an
   unknown host in the 'to' attribute and the error occurs during stream
   setup, the value of the 'from' attribute returned by the receiving
   entity in the stream header sent before termination MUST be either an
   authoritative hostname for the receiving entity or the empty string.

/psa

---

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 22:42:40 +0100

>   authoritative hostname for the receiving entity or the empty string.

WFM, thanks.

/K

---

From: Matthew Wild <[email-masked]>
Date: Mon, 7 Jun 2010 23:41:21 +0100

>> "How come I get an error from microsoft.com saying microsoft.com no

"How come I get an error from jabber.org for a stream I opened to
microsoft.com?"

> out what the authoritative hostname is at each address?

But as I mentioned in my earlier post, there is no single
authoritative hostname. But if there were, yes, I consider it an
unnecessary information leak. It certainly doesn't constitute an
"attack", however it may well be a means used to gain information to
aid in an attack (of some sort).

>   authoritative hostname for the receiving entity or the empty string.

Since it seems I'm outnumbered, I guess this will have to do :)

Thanks,
Matthew

---

From: Dave Cridland <[email-masked]>
Date: Tue, 08 Jun 2010 11:17:44 +0100

On Mon Jun  7 23:41:21 2010, Matthew Wild wrote:
> client -
Quite so, I'm not keen on this either.

> aid in an attack (of some sort).
I don't see any benefit in handing out the information without a  
pressing reason.

> special

Works for me.

Will an empty string work in the field, or should we consider a "."?  
I note that's used in SRV, so there is some precedence.

Dave.