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

Richard Barnes <rlb@ipv.sx> Fri, 11 July 2014 01:51 UTC

Return-Path: <rlb@ipv.sx>
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 974F71B2882 for <xmpp@ietfa.amsl.com>; Thu, 10 Jul 2014 18:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level:
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 WfVwpEg9O78P for <xmpp@ietfa.amsl.com>; Thu, 10 Jul 2014 18:51:43 -0700 (PDT)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A2D1B2816 for <xmpp@ietf.org>; Thu, 10 Jul 2014 18:51:42 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id l6so487361oag.0 for <xmpp@ietf.org>; Thu, 10 Jul 2014 18:51:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CIbtWZSv1qgd822kybRtVotI0CtML64I73fktrYKl8E=; b=HjM9y7ZY1wfI57CoRHdFvkVv9hsVvNrVsRmBd5hFWtqefNrSk9jXD9JjD08qZfM/jX GsicPuEPVLdv9GcdL4WPwJksyV1pLI/4rqSfyOnkUmfHOfpn0Pafo6AJhU1YAToZONWN z+KwGrbAcwuzFm9dDoyLIrg3GMzeo+fxOtHjQdAX4RGKglTroYwEYUmb2mrtfk4YtXyS gftJ6dkCfH0wt0ipzk5lYMt0HTilmeihu75q6LHnlnQ5xjnl/6B3IAevw1RU936Bw/fo dEKihqJF4NCBJyvz9Y3KtRhDWaqUH3fUOccCvPBWVYpFC96LRxRh3NcwLUXjKHxIeWoa /DSA==
X-Gm-Message-State: ALoCoQlFeLOHxGroYvd3tMVn7QVhMayRLtajBIjDiP90eClNu5uIaONBGkdXtOTDcKIzvCJHbHMz
MIME-Version: 1.0
X-Received: by 10.182.250.196 with SMTP id ze4mr59691029obc.46.1405043501988; Thu, 10 Jul 2014 18:51:41 -0700 (PDT)
Received: by 10.60.54.38 with HTTP; Thu, 10 Jul 2014 18:51:41 -0700 (PDT)
In-Reply-To: <53BF3C04.80600@stpeter.im>
References: <53BF3C04.80600@stpeter.im>
Date: Thu, 10 Jul 2014 21:51:41 -0400
Message-ID: <CAL02cgQvRt2T7M_+UfdoPpxkGQVvxyS6HUYyyyMjyDKWwMtFyw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: multipart/alternative; boundary=001a11c1dcb8d49ec204fde12e9c
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/iOqeBazSQn_z21eZ4GXzqgPvU3U
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [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:51:45 -0000

On Thu, Jul 10, 2014 at 9:21 PM, Peter Saint-Andre <stpeter@stpeter.im>
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/>)t;).
>
> Let me know if you have any questions or comments.
>
> Thanks!
>
> Peter
>