[xmpp] next steps on draft-ietf-xmpp-websocket
Peter Saint-Andre <stpeter@stpeter.im> Fri, 11 July 2014 01:21 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07881A008D for <xmpp@ietfa.amsl.com>; Thu, 10 Jul 2014 18:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.953
X-Spam-Level:
X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT3mRklWUVdc for <xmpp@ietfa.amsl.com>; Thu, 10 Jul 2014 18:21:10 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DF8661A0039 for <xmpp@ietf.org>; Thu, 10 Jul 2014 18:21:09 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13E1740E62; Thu, 10 Jul 2014 19:21:08 -0600 (MDT)
Message-ID: <53BF3C04.80600@stpeter.im>
Date: Thu, 10 Jul 2014 19:21:08 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: XMPP Working Group <xmpp@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/GUftTR3KUxRYHAbHZ5SnN55FlZc
Subject: [xmpp] next steps on draft-ietf-xmpp-websocket
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jul 2014 01:21:12 -0000
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? 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] next steps on draft-ietf-xmpp-websocket Peter Saint-Andre
- Re: [xmpp] next steps on draft-ietf-xmpp-websocket Richard Barnes