next steps on draft-ietf-xmpp-websocket
Peter Saint-Andre <stpeter <at> stpeter.im>
2014-07-11 01:21:08 GMT
Dear Authors and WG,
This morning, at Richard's invitation and as the document shepherd for
draft-ietf-xmpp-websocket, I briefly joined the IESG telechat to talk
through the DISCUSS positions lodged by Stephen Farrell and Ted Lemon:
As a result, I'd like to ask the authors to complete several tasks (and
I will be happy to propose or help with text for these items, since I
was present during the IESG discussion):
1. More clearly describe the delegation scenario outlined in the second
paragraph of Section 6:
Browser based applications are not able to inspect and verify at the
application layer the certificate used for the WebSocket connection
to ensure that it corresponds to the domain specified as the "to"
address of the XMPP stream. For hosts whose domain matches the
origin for the WebSocket connection, that check is already performed
by the browser. However, in situations where the domain of the XMPP
server might not match the origin for the WebSocket endpoint
(especially multi-tenant hosting situations), the web host metadata
method (see [RFC6415] and [XEP-0156]) MAY be used to delegate trust
from the XMPP server domain to the WebSocket origin.
In particular, it would be very helpful to add two examples (one in
which the WebSocket origin matches the domain of the XMPP service, and
one in which it does not, e.g., delegation of foo.example to
hosting.example.net) and to explain that the delegation model is
conceptually the same as for the existing DNS SRV lookup methods
described in RFC 6120, except using web linking in the WebSocket case.
Extra credit for walking through the examples in enough depth that
readers of this document can see all the key the steps involved (go to
HTTPS URL at source domain for host-meta data, retrieve the appropriate
web link, resolve that link to an IP address, connect there via wss: URI
or HTTP upgrade, etc. - and what certificate to check at the end of that
process, tying in with RFC 2818 for checking rules).
2. In Section 6.1, briefly describe why the choice of transport binding
(WebSocket here vs. TCP as in RFC 6120), including the different message
framing method used here, does not have an impact on the effectiveness
of end-to-end stanza encryption methods.
3. There was a bit of confusion (reflected in Ted Lemon's DISCUSS) about
the exact purpose of the WebSocket binding. To clear up this confusion,
it would be good to explain that the WebSocket binding is an alternative
way to interact with the same service that one might interact with using
the TCP binding (in an IM context, one would be able to retrieve the
same contact list, chat with the same people, etc.). That is, the point
of the WebSocket binding is mainly to enable browser-based clients to
connect to servers (in a more efficient way than BOSH), since such
clients don't have access to facilities that would enable them to open
TCP connections as in RFC 6120. It would be best if one aspect of this
explanation would include a discussion of the security context for
web-based interactions with XMPP services - e.g., the web origin concept
(RFC 6454) applies, discovery occurs via host-meta and web linking, and
browsers don't allow access to the application-layer certificates
(perhaps there are other salient points to raise here, too, but those
seem like the key ones to me).
Richard, does that accurately summarize the discussion?
Naturally, the authors also need to address the various other comments
provided by IESG members (again, see
Let me know if you have any questions or comments.