Re: next steps on draft-ietf-xmpp-websocket

On Thu, Jul 10, 2014 at 9:21 PM, Peter Saint-Andre <[email protected]>
wrote:

> 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:
>
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/
>
> 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?
>

Yes, that sounds accurate -- though I think the required text will take
less space than the summary :)

--Richard

Naturally, the authors also need to address the various other comments
> provided by IESG members (again, see <
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/>).
>
> Let me know if you have any questions or comments.
>
> Thanks!
>
> Peter
>

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp