[xmpp] Fwd: New Version Notification for draft-ietf-xmpp-websocket-01.txt

Lance Stout <lance@andyet.net> Fri, 14 February 2014 18:13 UTC

Return-Path: <lance@andyet.net>
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 7B2D61A0396 for <xmpp@ietfa.amsl.com>; Fri, 14 Feb 2014 10:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=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 FWCsKJAnFfQJ for <xmpp@ietfa.amsl.com>; Fri, 14 Feb 2014 10:13:20 -0800 (PST)
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id B34301A037E for <xmpp@ietf.org>; Fri, 14 Feb 2014 10:13:20 -0800 (PST)
Received: by mail-pa0-f54.google.com with SMTP id fa1so12708644pad.27 for <xmpp@ietf.org>; Fri, 14 Feb 2014 10:13:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=JpuXShQFux2LnK9FCta90EA5BkbnmRXE4m9YSG6U9Cc=; b=CaMicH3B3aldmZj3k+ACHFtj21+KHiCOGSdwdkaMEIsrF9fj8CI86USzzF6O0+J1MW /5gEJHLrbf4iYoSD523OH3x9hjLeWuNkww/OCSf5q7Fdyf8Hu3ZXQ5I5jCYqmji1udWc dj8gH9TgSke546+QP2wEASzySKOXsvlnLhm2i9Ak6OyfY4gc45mksQac5iAmW58kbKMZ YYNa2TEnrr21X9ebTnsFcZCD+GRDaT/CxSN8YoNRwLoaAbg+8zSmUZz2sWftYmpEccp4 dGZxu8FuvrkXYSa0XKo9dF75ILrtUChMSNdB/FJDmHcEv4O+wGDoG3rsJV+qNrwPrNRO YDjA==
X-Gm-Message-State: ALoCoQkFNItqBFECkQebXZcWwvh6Qt++yzrqySZeDUNG6Hj5pmboegYMawIVFdr7uH5Vwb6kDsBl
X-Received: by 10.66.118.71 with SMTP id kk7mr10510304pab.14.1392401599226; Fri, 14 Feb 2014 10:13:19 -0800 (PST)
Received: from [10.0.2.180] (71-84-176-17.dhcp.mdfd.or.charter.com. [71.84.176.17]) by mx.google.com with ESMTPSA id cz3sm19449418pbc.9.2014.02.14.10.13.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 10:13:18 -0800 (PST)
From: Lance Stout <lance@andyet.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_37C2A9B7-11F0-4BBB-A4FB-11A5DFDB07E7"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Fri, 14 Feb 2014 10:13:16 -0800
References: <20140214172839.3876.31414.idtracker@ietfa.amsl.com>
To: XMPP Standards <standards@xmpp.org>, XMPP Working Group <xmpp@ietf.org>
Message-Id: <74E82CC3-D0CD-4958-86F0-43013FF8D1DD@andyet.net>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VmrxCki-JBGKF16cDHQEff1tOcc
Subject: [xmpp] Fwd: New Version Notification for draft-ietf-xmpp-websocket-01.txt
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, 14 Feb 2014 18:13:23 -0000

This XMPP over WebSocket draft update warrants some discussion, and will need a good dose of feedback.


1) Using new open/close elements.

At the last IETF meeting we outlined how new open/close elements would work, but we didn't quite reach consensus on if that approach should used (discussions both on and off list resulted in people swapping sides repeatedly). However, after informal discussions at the XSF Summit in Brussels between those of us who expressed preference on list for the existing <stream /> method, I believe we have now reached consensus to use the new open/close elements.


The summary of the new open/close approach is:

-- Starting a stream (success)
=== Establish WebSocket === 
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
         version="1.0"
         id="..."
         to="example.com"
         from="client@example.com" />

S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
         version="1.0"
         id="..."
         to="client@example.com"
         from="example.com" />


--- Starting a stream (error)
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
         version="1.0"
         id="..."
         to="example.com"
         from="client@example.com" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
         version="1.0"
         id="..."
         to="client@example.com"
         from="example.com" />
S: <error xmlns="http://etherx.jabber.org/streams">
     ... 
   </error>
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" />
C: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" />
=== Close WebSocket === 


-- Closing a stream
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" />
C: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" />
=== Close WebSocket ===


In addition, every WebSocket message MUST be a full, well-formed XML fragment with all relevant namespace and xml:lang declarations. There was concern before about the bandwidth increase this would cause, but it should be noted that WebSocket compression is well underway and has implementations in browsers now (with sliding zlib window between message frames).



As should be obvious, but I will state it to be clear: this is a BREAKING change. Given the relatively small number of existing implementations and production deployments, I hope we can get everything switched over fairly quickly. 



2) The see-other-uri issue

With the new <close /> element, we now have a way to express see-other-uri behaviour:

<close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
       see-other-uri="wss://example.com/xmpp-binding" />


3) Security Considerations

Most of the security considerations we've discussed are due to the browser not exposing the information we traditionally need to perform peer verification. We have concluded before that in most cases, a browser-based client will be served from the same domain as the XMPP server and WebSocket endpoint, and be hardcoded to use the correct endpoint; however, there still are some gaps in multi-tenant situations and for browser-based clients intended to be used with any domain.

At the XSF, we have updated XEP-0156 (Discovering Alternative XMPP Connection Methods) to include an HTTPS lookup method. A neat side effect of that approach is that it lets us have 'POSH-lite', allowing a client to establish a trust relationship between the targeted XMPP domain and its WebSocket endpoint (with caveats of not allowing downgrades from wss to ws, etc). As far as I'm aware, that seems to be the most we can do in this area.




— Lance


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-ietf-xmpp-websocket-01.txt
> Date: February 14, 2014 at 9:28:39 AM PST
> To: Eric Cestari <eric@cestari.info>fo>, "Lance Stout" <lance@andyet.net>et>, "Jack Moffitt" <jack@metajack.im>im>, Lance Stout <lance@andyet.net>et>, "Eric Cestari" <eric@cestari.info>fo>, Jack Moffitt <jack@metajack.im>
> 
> 
> A new version of I-D, draft-ietf-xmpp-websocket-01.txt
> has been successfully submitted by Lance Stout and posted to the
> IETF repository.
> 
> Name:		draft-ietf-xmpp-websocket
> Revision:	01
> Title:		An XMPP Sub-protocol for WebSocket
> Document date:	2014-02-14
> Group:		xmpp
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-xmpp-websocket-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-xmpp-websocket-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-01
> 
> Abstract:
>   This document defines a binding for the XMPP protocol over a
>   WebSocket transport layer.  A WebSocket binding for XMPP provides
>   higher performance than the current HTTP binding for XMPP.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>