Subject: [xmpp] WGLC of draft-ietf-xmpp-websocket-02

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Apr 2014 16:29:56 -0500

This is a Working Group Last Call of draft-ietf-xmpp-websocket-02. The draft is available at the following URL:

http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02

The WGLC will conclude on 21 April, 2014. Please send your comments to the authors and the XMPP mailing list.

Thanks!

Ben.

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 09 Apr 2014 21:48:35 +0200

I generally consider this draft to be in a decent shape. The wording and
general flow still seem a bit rough to me at times. More detailed
comments below:

= Substantive =
* Having some text explaining the general framing approach upfront
  would be helpful. This should note that an XML Stream is not used as
  described in RFC 6120, but <open/> and <close/> elements are used
  instead. The lack of a surrounding <stream:stream> element should
  be explicitly noted. This could go along with text explaining each
  message is a full XML document without an XML declaration.

3.5 Closing the connection:
 * "To initiate closing the WebSocket connection, the closing party MUST
   send a normal WebSocket close message with an empty body."
   Why? Having no body at all implies that sending a status code
   is not allowed. This seems undesirable to me.

3.5.1 see-other-uri
 * This currently says that the URI may only point to another WebSocket
   endpoint. IIRC the intent was specifically to be able to also move
   from WebSocket to BOSH.

= Editorial =
1. Introduction:
 * "The WebSocket protocol [...]. The WebSocket protocol [...]."

3.3 XMPP Stream Setup
 * It would be helpful to reuse RFC 6120's language here.
   I.e. "The first message sent by the initiating entity [...]"
   "The receiving entity MUST respond [...]"

3.6 Stanzas
 * "directly over the XMPP stream", RFC 6120 calls this a "XML Stream".
 * "XML text declaration" XML 1.0 calls this a "XML declaration",
   the whole sentence could use some rewording, possibly also mentioning
   size overhead.

3.7 Stream Restarts
 * "In these cases", only one case is listed. Possibly reword to say
   something like "Whenever a stream restart is mandated [...]"
   Clarify <open/> is used for stream restarts instead of
   <stream:stream>.

3.8 Stanzas
 * "that the XMPP stream is still alive" -> "XML Stream"

Regards,
Florian Zeitz

---

From: Sergey Dobrov <[email-masked]>
Date: Wed, 09 Apr 2014 21:07:50 +0200

Hello,

We've implemented the protocol in our JSLiX library here:
https://github.com/jbinary/jslix/blob/master/src/connection.transports.websocket.js

and it seems to work well in couple with prosody xmpp server, we had no 
any problems with the spec.

The implementation have not been used at production server but seems to 
work pretty stable on localhost and will go to production soon.

Thanks.

---

From: Lance Stout <[email-masked]>
Date: Thu, 10 Apr 2014 22:39:44 -0700

I agree with all of the points that Florian raised, and will edit and push an updated I-D incorporating that feedback over the weekend.

-- Lance

---

From: Gordin <[email-masked]>
Date: Mon, 21 Apr 2014 01:23:24 +0200

I implemented all of the websocket drafts for Strophe.js and found
most of it straightforward, but I have a few minor clarifications to
add for "3.4.  Stream Initiation" (in the -03 version).

It reads
"The first message sent by the initiating entity after the WebSocket
opening handshake is complete MUST be an <open/> element qualified by
the "urn:ietf:params:xml:ns:xmpp-framing" namespace. The 'from', 'id',
'to', and 'version' attributes of this element mirror those of the
XMPP opening stream tag as defined for the
'http://etherx.jabber.org/streams' namespace in XMPP [RFC6120]."

The first sentence could be rearrenged to
"The first message sent after the WebSocket opening handshake is
complete MUST be an <open/> element qualified by the
"urn:ietf:params:xml:ns:xmpp-framing" namespace by the initiating
entity."
to emphasize that the initiating entity has to send the first message
after the handshake.
More important though, "The 'from', 'id', 'to', and 'version'
attributes of this element …" suggests that the the initiating entity
should include an 'id' attribute in the <open/> element, which is a
MUST NOT in RFC6120 as this 'id' "MUST be generated by the receiving
entity" and "the initiating entity MUST NOT include the 'id'
attribute" as stated in
http://tools.ietf.org/html/rfc6120#section-4.7.3 . It would be nice if
there was an example and a reference to RFC6120, section 4.7.3 to make
it clear that the 'id' attribute should only be present in the
response of the receiving entity. Something like:

   C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
            to="example.com"
            version="1.0" />
   S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
            id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
            to="example.com"
            version="1.0" />

-- Gordin

2014-04-07 23:29 GMT+02:00 Ben Campbell <[email-masked]>:
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Lance Stout <[email-masked]>
Date: Sun, 20 Apr 2014 16:50:50 -0700

On Apr 20, 2014, at 4:23 PM, Gordin <[email-masked]> wrote:

> **snip**
> — Gordin

Thank you, Gordin. I've posted a -04 draft that incorporates your feedback.

I also added in the new example of a successful opening exchange the use of the xml:lang attribute, as I noticed that had not been mentioned.

— Lance

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Apr 2014 16:49:42 -0500

Hi,

The WGLC has completed. Authors, please let the list know when you believe all feedback has been addressed. (Note: "addressed" does not necessarily mean "accepted".)

Thanks!

Ben.

---

From: Lance Stout <[email-masked]>
Date: Tue, 22 Apr 2014 16:29:10 -0700

> The WGLC has completed. Authors, please let the list know when you believe all feedback has been addressed. (Note: "addressed" does not necessarily mean "accepted".)

Draft -06 has been published, which I believe addresses all feedback so far.

I note there is a pending question on connection managers, but I don't believe that the use of a connection manager affects any of the actions prescribed in the latest document. CMs should be transparent.

We do have Security Considerations listed in XEP-0124 for BOSH connection managers, which amount to 'use TLS from the CM to the backend', and 'use e2e encryption on the client' because guaranteeing anything about a CM's behaviour is beyond scope. I can expand the Security Considerations for this document to do the same, if people deem that necessary.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 23 Apr 2014 14:01:45 -0500

Hi Florian, Sergey, and Gordin (and any WGLC commenters that I might have missed)

Can you confirm to the list that your comments have been addressed, either in the current version or through conversation?

Thanks!

Ben.

On Apr 22, 2014, at 6:29 PM, Lance Stout <[email-masked]> wrote:

> We do have Security Considerations listed in XEP-0124 for BOSH connection managers, which amount to 'use TLS from the CM to the backend', and 'use e2e encryption on the client' because guaranteeing anything about a CM's behaviour is beyond scope. I can expand the Security Considerations for this document to do the same, if people deem that necessary._______________________________________________
> xmpp mailing list
> [email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 23 Apr 2014 14:24:27 -0500

> We do have Security Considerations listed in XEP-0124 for BOSH connection managers, which amount to 'use TLS from the CM to the backend', and 'use e2e encryption on the client' because guaranteeing…

So here's the basis of all of my connection manager questions. This may be based on a completely wrong understanding of connection managers on my part, so do not hesitate to tell me I am clueless if that's the case. :-)

If an XMPP implementation, especially a server, is behind a connection manager, is it aware of that fact? Is it assumed to implement this draft? Are we requiring special behavior of the server, without the server knowing it needs to do it?

If the answer is yes, then I may have concerns in two areas:

1) Is the connection manager expected to "adapt" server behavior to follow this draft?

2) What is the impact of adding a new TLS intermediary, when the server expects a direct SA with the client? Your comment above _might_ be sufficient, but is there any plain vanilla XMPP server behavior and/or security assumptions that break down? Any concerns from a SASL perspective?

---

From: Lance Stout <[email-masked]>
Date: Tue, 29 Apr 2014 22:06:41 -0700

> If an XMPP implementation, especially a server, is behind a connection manager, is it aware of that fact?

No. It is either aware because the two were configured in tandem within the same administrative context, or it sees what appear to be standard TCP C2S sessions.

> Is it assumed to implement this draft? Are we requiring special behavior of the server, without the server knowing it needs to do it?

It is not assumed that the server does anything special to facilitate using this draft. In that case a CM would need to translate the TCP C2S session to this draft.

> 1) Is the connection manager expected to "adapt" server behavior to follow this draft?

If the target server does not support this draft natively, then a CM will have to:

1. Translate the <open/> and <close/> elements back and forth from <stream:stream />
2. Emit <close/> elements with see-other-uri values, as needed by the CM
3. For any other terminal CM condition, emit the corresponding traditional stream error (NOTE: This case is not mentioned in the draft)
4. Marshal all other stanzas and top level elements in and out of WebSocket message frames

> 2) What is the impact of adding a new TLS intermediary, when the server expects a direct SA with the client? Your comment above _might_ be sufficient, but is there any plain vanilla XMPP server beh…

I'm not aware of any new difficulties here; the same situations exist for BOSH already. A server that expects to use mechanisms which assume no intermediaries will fail (as designed!) when put behind a CM that can not share such information with the server. So SCRAM-SHA-1-PLUS will fail, as well as EXTERNAL with client certs. Note that we aren't able to use SCRAM-SHA-1-PLUS in the browser anyway, as we can't access channel binding information.

I can imagine for large deployments, the CM could contain the authentication logic, passing on a trusted authenticated stream to the main XMPP server for routing. In which case, the CM is again transparent to the user and acts purely as part of a larger, logical XMPP server.

—Lance