Re: [secdir] Reviews of draft-ietf-xmpp-websocket-07

Lance Stout <> Fri, 04 July 2014 02:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D92761B297B for <>; Thu, 3 Jul 2014 19:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hcAm3buXJDFG for <>; Thu, 3 Jul 2014 19:30:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0643C1B298B for <>; Thu, 3 Jul 2014 19:30:46 -0700 (PDT)
Received: by with SMTP id fp1so1159697pdb.25 for <>; Thu, 03 Jul 2014 19:30:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5jp7ssa4ZDuyUnV5HqgJtNJeBetX4mrY5ee+CL3iIVw=; b=VXVqIIvkOD6nlY2XfXcRc0WYwdcgpZD/OStJgPGdCk6WoZbd2mYHqHlwDxRksA4Hbb +Lwk3vtxYKmQY4kJ/Zy9f2xnsWQA5Pd46dtP7CC4PMbNap9EIZU+2nuckbikNKomJZV1 WJjm46nxumspy9JVFr2nrZ7wdM7J/FWv4B2PuSAaIXHSExsTh6a8MzH3WDOrsU7HjQaN K3YyRojhdg42sUNer8VUM0rgqTkHk6oPROBxdIbQAO3hrlO2t2GfExMudaLQHYjw4bkI FJhVruhExf0YMe+FPMseYQ29elLCtozPtMJ78ykAaiik+aOyXGbYEqTZca/QTKYg/bG6 PSJA==
X-Gm-Message-State: ALoCoQmC9Sk5TslCYdnUHoL2zKepR8vbH7YOyPOyeN5uILPwetxkwOtE/M99ClRiWHcHhEpbkmam
X-Received: by with SMTP id a1mr7552927pdd.13.1404441046639; Thu, 03 Jul 2014 19:30:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h15sm6709498pdl.5.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 19:30:45 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_1F4FC48B-2C42-4B9B-A09F-838E4C7BB53A"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Lance Stout <>
In-Reply-To: <>
Date: Thu, 03 Jul 2014 19:30:43 -0700
Message-Id: <>
References: <> <>
To: "" <>
X-Mailer: Apple Mail (2.1878.2)
X-Mailman-Approved-At: Fri, 04 Jul 2014 07:01:54 -0700
Cc:, "" <>,, "" <>, "Romascanu, Dan (Dan)" <>,, "" <>
Subject: Re: [secdir] Reviews of draft-ietf-xmpp-websocket-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jul 2014 02:30:50 -0000

Closing in on the end of LC for draft-ietf-xmpp-websocket-07, so replying to the
feedback generated so far. We'll publish a -08 draft addressing these issues,
which have all been minor or editorial points.

On Jul 3, 2014, at 9:39 AM, <> <> wrote:

> Should “when TLS is used, it MUST be enabled the WebSocket layer ” have read
> “when TLS is used, it MUST be enabled at the WebSocket layer ” ?

Yes, that is the intended wording.

On Jul 2, 2014, at 6:00 AM, Romascanu, Dan (Dan) <> wrote:

> 1. In order to accommodate the Websocket binding this document describes several
> deviations from RFC6120. For example, in Section 3.3 it says: The WebSocket
> XMPP sub-protocol deviates from the standard method of constructing and using
> XML streams as defined in [RFC6120] by adopting the message framing provided by
> WebSocket to delineate the stream open and close headers, stanzas, and other
> top-level stream elements. I am wondering whether it would not be appropriate to
> reflect this in the document header by adding Updates RFC6120

This is a separate binding from the TCP binding defined in RFC6120, so I don't
think saying Updates RFC6120 would be accurate. Nothing in RFC6120 is modified
by this document.

> 2. In Section 3.6.1:
>    If the server wishes at any point to instruct the client to move to a
>    different WebSocket endpoint (e.g. for load balancing purposes), the server
>    MAY send a <close/> element and set the "see-other-uri" attribute to the
>    URI of the new connection endpoint (which MAY be for a different transport
>    method, such as BOSH (see [XEP-0124] and [XEP-0206]).
>         I do not understand the usage of MAY in this paragraph. Is there another
> method to move to a different Web socket endpoint that is described here or some
> other place? In not, why is not the first MAY at least a SHOULD? The second
> usage seems to describe a state of facts, so it needs not be capitalized at all.

That is the only method, so I agree that can be a SHOULD, and also agree on the
second point.

> In Section 3.1 I believe that the example should be preceded by some text
> that indicates that this is an example, such as: ‘An example of a successful
> handshake and start of session follows:’

+1, will add that.

On Jun 25, 2014, at 11:55 PM, Juergen Schoenwaelder
<> wrote:

> - Sec 1: The term 'raw socket' can be potentially mis-understood, perhaps simply
> remove 'over row sockets' completely (I think the message of the sentence
> remains intact without these words).

+1 will change

> - Sec 3.1: The text says that both client and server MUST have |xmpp| in the
> list of protocols for the |Sec-WebSocket-Protocol| header. The text does not
> detail what happens if this is not the case. Is there be a defined behavior if
> this protocol negotiation fails?

Good catch, RFC6455 doesn't describe what to do in that case, so we'll need to
address it.

If the server does not reply with 'xmpp' in the Sec-WebSocket-Protocol handshake
reply, then the client MUST close the connection.

> - Sec 3.6.1: There is a closing parenthesis missing at the end of the first
> paragraph.

Noted, will fix.

- Lance