Re: [xmpp] Comments/Questions on draft-ietf-xmpp-websocket

[Lance Stout <[e-mail]>]

On Nov 5, 2013, at 10:25 AM, Ben Campbell <[e-mail]> wrote:

> (As individual)
> 
> -- section 3.5:
> 
> Does it make sense to distinguish a “clean” closure from otherwise? (Perhaps with a MUST close the stream for a clean closure...)

Yes, it does make sense in the context of using XEP-0198 for stream management. I thought I had that defined, but it looks like one more sentence making that more explicit would be good.

> -- 3.8:
> 
> Is the client expected to know if it’s talking to a connection manager rather than the xmpp server?
> 
> -- 3.9:
> 
> Does this create problems if a server wants to force TLS? 
> 
> What are the security associations if a connection manager is in the path? Is it possible to have an e2e TLS SA between client and server if there’s a connection manager?


IMO, the concept of third-party connection managers needs to go away. 

From the consuming side, I only see 'The XMPP Server' whose domain matches the cert used by the WebSocket connection. Now, in reality I may be talking to an intermediate connection manager/load balancer, but it is one provided by the same organization as the XMPP server proper and with the same level of trust (of course, using TLS for internal server links looks to be a good idea nowadays).

But, what if you want to use a connection manager to establish a WebSocket connection to a domain that does not natively provide WebSocket access? You could use your own personal manager, in which case the trust issue goes back to that of a normal TCP session as long as you trust yourself for the security of the WebSocket data. However, it's game over security-wise if you have to use someone else's connection manager because the data has to be converted back to plaintext for WebSocket, particularly in order to satisfy the framing requirements.

FWIW, from my experience, third-party connection managers are only used for Facebook.


> -- 4:
> 
> Should this section have normative language?
> 
> This section has an informative reference to XEP-0156. On a quick read, I wonder if that should not be normative, in the sense that one needs to understand XEP-0156 to understand this section. OTOH, the DNS use of XMPP over TCP is defined in 6120, as it's pretty core to the protocol. Is it appropriate to reference a XEP for something like that?
> 
> (I note that Peter said in a separate email that this XEP is about to change. But I'm not sure that changes my concern about referencing a XEP for something this fundamental to the protocol.)

No opinion here either way. The updated XEP-0156, if accepted, would be a much nicer fit than the DNS method (by using the browser-accessible .well-known/host-meta file). We already have RFC 6120 referencing XEP-0156 for fallback discovery mechanisms. 

Ben: Are you suggesting that XEP-0156 needs to become an RFC or incorporated into 6120bis?

> -- 5 (security considerations)
> 
> Seems like we need more here. Is authentication still at xmpp level? (there's a brief mention of sasl handshakes—does anything change? If not, say so.)

Good point. Consensus at one point was that authentication *can* be done at the WebSocket level (auth headers/session cookie/etc), but that a SASL EXTERNAL would be needed at the XMPP layer for it. I think this should be revisited Friday.

> It’s probably worth noting that ws prevents you from using the cert toauthorize the xmpp service, rather than just the ws service. is that okay?

Right, that would be an issue for third-pary connection managers. For a first party service, I think the WS server and the XMPP server should be responding as the same domain, since there is no distinguishing difference to the end client.

> In general, I think we need to address the tension between XMPP/WebSocket removing some degree of application layer control over how TLS is used, while  at the same time we have a draft from Peter that proposes to strengthen the rules for TLS in XMPP. I don't necessarily know whether that's a problem or not--but we should explicitly discuss it and document that discussion here.

+1 to discussion.


-- Lance