Subject: [xmpp] See-other-uri and insecure web sockets

From: Jonathan Lennox <[email-masked]>
Date: Tue, 4 Mar 2014 15:31:20 +0000

As requested — I reviewed the text forbidding see-other-uri downgrading in the current version of draft-ietf-xmpp-websocket, and I’m happy with it.

What I was responding to at the mic was a comment that StPeter made during his presentation, suggesting that in addition, a future version of the draft would recommend that see-other-uri received over an insecure (ws or http) connection should be ignored.

I think this is a bad idea — I don’t see any reason why see-other-uri should be any less trusted than anything else received over an insecure connection.  And indeed, I think that most servers (if they have a ws listener at all) would want to respond to insecure XMPP connections by sending a see-other-uri pointing at their wss uri!

---

From: Kevin Smith <[email-masked]>
Date: Tue, 4 Mar 2014 16:44:28 +0000

On Tue, Mar 4, 2014 at 3:31 PM, Jonathan Lennox <[email-masked]> wrote:
> As requested -- I reviewed the text forbidding see-other-uri downgrading in the current version of draft-ietf-xmpp-websocket, and I'm happy with it.
>

It feels to me like there are potentially auth mechanism downgrade
attacks associated here, if people were to do the Wrong Thing. So I
think at least a note is worthwhile.

The document does, though, tell everyone to do wss, so this is
arguably not an issue.

>
> I think this is a bad idea -- I don't see any reason why see-other-uri should be any less trusted than anything else received over an insecure connection.  And indeed, I think that most servers (if they have a ws listener at all) would want to respond to insecure XMPP connections by sending a see-other-uri pointing at their wss uri!

I think this scenario is somewhat unlikely - in this case the
discovery would have pointed to was (either hard-coded or over 156 or
whatever).

/K

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 4 Mar 2014 18:02:30 +0000

> discovery would have pointed to was (either hard-coded or over 156 or

Well, you need to do *something* if someone tries to connect to <ws://websocketserver.example/xmpp-bind>, but I guess responding with 301 or 404 to the HTTP handshake, prior to protocol handover, would be better than switching to xmpp and then using see-other-uri.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Mar 2014 01:42:46 +0000

> Well, you need to do *something* if someone tries to connect to <ws://websocketserver.example/xmpp-bind>, but I guess responding with 301 or 404 to the HTTP handshake, prior to protocol handover, w…

Yes, I think that's the better approach - the earlier the better.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Mar 2014 01:43:26 +0000

> The document does, though, tell everyone to do wss, so this is

Personally I see no harm in a bit of text that reinforces the point.

Peter

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 09:29:55 +0000

> Yes, I think that's the better approach - the earlier the better.

Does that mean we don't need see-other-uri at all?

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Mar 2014 09:39:45 +0000

> Does that mean we don't need see-other-uri at all?

No, it means that if the client tries to go to an http or ws URI, it is 
best for the service to redirect to an https or wss URI using standard 
HTTP methods, not XMPP methods. We still need the see-other-uri for more 
advanced scenarios in the XMPP context - typically, telling the client 
about an alternative or fallback WebSocket endpoint, just like 
see-other-host from RFC 6120 but for WebSocket endpoints instead of TCP 
endpoints.

Peter

---

From: Matt Miller <[email-masked]>
Date: Wed, 5 Mar 2014 10:36:14 +0000

On 3/5/14, 9:29 AM, Ben Campbell wrote:
>>> Well, you need to do *something* if someone tries to connect to
>>> <ws://websocketserver.example/xmpp-bind>, but I guess
>>> responding with 301 or 404 to the HTTP handshake, prior to
>>> protocol handover, would be better than switching to xmpp and
>>> then using see-other-uri.
>> 
> _______________________________________________ xmpp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/xmpp
> 

There are (and will be) cases where a redirect cannot be done until
after the XMPP-over-Websocket handshake is started (well after an HTTP
redirect is possible).

We still need this.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.