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

Richard Barnes <> Fri, 11 July 2014 01:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 974F71B2882 for <>; Thu, 10 Jul 2014 18:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.377
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WfVwpEg9O78P for <>; Thu, 10 Jul 2014 18:51:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5A2D1B2816 for <>; Thu, 10 Jul 2014 18:51:42 -0700 (PDT)
Received: by with SMTP id l6so487361oag.0 for <>; Thu, 10 Jul 2014 18:51:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id ze4mr59691029obc.46.1405043501988; Thu, 10 Jul 2014 18:51:41 -0700 (PDT)
Received: by with HTTP; Thu, 10 Jul 2014 18:51:41 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 10 Jul 2014 21:51:41 -0400
Message-ID: <>
From: Richard Barnes <>
To: Peter Saint-Andre <>
Content-Type: multipart/alternative; boundary=001a11c1dcb8d49ec204fde12e9c
Cc: XMPP Working Group <>
Subject: Re: [xmpp] next steps on draft-ietf-xmpp-websocket
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>

> 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
> 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 :)


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.
> Thanks!
> Peter