Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

"Roy T. Fielding" <> Tue, 06 September 2011 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA86921F8E53; Tue, 6 Sep 2011 12:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.293
X-Spam-Status: No, score=-105.293 tagged_above=-999 required=5 tests=[AWL=-2.694, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JBtsEhgzrp0Y; Tue, 6 Sep 2011 12:54:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3089F21F8E3B; Tue, 6 Sep 2011 12:54:41 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 84EAD438081; Tue, 6 Sep 2011 12:56:28 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 1393E438072; Tue, 6 Sep 2011 12:56:28 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Tue, 6 Sep 2011 12:56:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Joel Martin <>
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP <>,,
Subject: Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2011 19:54:42 -0000

On Sep 3, 2011, at 11:51 AM, Joel Martin wrote:

> You may feel that the wording of your note is not pejorative (because what you wanted to say is so much more so), but the tone and wording come across that way even if it is technically accurate.

Of course it is pejorative.  How can I explain this any better?
The technique being used by WebSockets to bypass organizational
security will cause deliberate harm to those networks which are
actively monitoring standard ports for attacks of various sorts.
It will also cause harm to existing HTTP services because the
additional content scanning will cause all network services on
those ports to be slowed.

Causing harm is bad.  I don't have non-pejorative words for it.

The sole reason for this harm is because the individuals who
organized this working group believe it is "too difficult" to
introduce new Internet protocols on their own ports.  The IESG
may or may not wish to respect those people's desires, since
they clearly are not managers of corporate networks, but I think
they would at least like to warn network managers that such a
thing is coming their way.  That is why we have IESG notes.

> Having a note in the spec that WebSocket connections over port 80 and 443 wlll have traffic patterns that are substantially different than normal HTTP patterns and how this might impact existing infrastructure is probably worthwhile but I don't think most of your note is helpful or serves much purpose (except as a passive aggressive way to express an opinion that the current WebSocket protocol is fatally flawed).
> Just one example: "convoluted and inefficient". A simple 4-byte running XOR hash is convoluted? Certainly it's slightly more complicated than raw bytes or plain text. But convoluted seems like a stretch by any measure. Inefficient? Again, it's obviously more inefficient than just passing bytes, but if you are going to do an operation to a series of bytes, it doesn't get much more efficient than XOR. And there was a fair bit of testing of the efficiency of different hashing algorithms on different platforms and this current algorithm was deemed not overly inefficient (if you disagree, please provide data).

I am a server developer.  Yes, it is obviously more inefficient
to change every byte, just as it is obviously convoluted to exchange
a true random hash key as part of the connection set-up.  Using TLS
all the time would have been just as complex but far less convoluted
(TLS is well-tested, deployed, and frequently implemented in hardware).
And let's not forget that the initial setup exchange itself (Upgrade)
is also required for the sole purpose of doing this over ports 80/443.
All of it, BTW, just to invoke a generic framing session that handles
some of TCP over TCP (without adding anything interesting by default,
like a MUX layer).

> So I think your real objection is that the current WebSocket protocol is more complicated and more inefficient than if WebSockets used a new set of well defined ports (without the ability to pick other ports, or with 80 and 443 explicitly disallowed or the same problem crops up again) and was able to safely send data without hashing. In which case I think your real disagreement is not with the outcome of the working group but with requirement #7 (#6 in the original) of the WebSocket requirements document: 

My disagreement is with the content of a proposed standard.

I don't care what the WG thinks its requirements are, nor
how it has made decisions on the basis of those requirements.
As I said before, I found it useless to participate within
the WG under those conditions because they were deliberately
designed to fail.  So, I stopped participating.  That does not
mean the WG deliverables are not subject to last call review.

> Personally, I think the ability to use port 80 and 443 for WebSockets is valuable and worthwhile and I agree with the requirement. But those ports are not mandatory (just defaults) and if it turns out that this is a mistake then it really isn't that difficult for web servers to deny WebSocket handshakes on port 80,443 and force WebSocket services to use other ports. It would also be simple to update the spec in the future and make client-to-server masking optional for ports that are not 80/443.

I think the note should reflect what has been specified, not what
might be specified at some point in the future.

Yes, if the protocol had been specified as "try this new port first
and only fall back to 80/443 as a last resort" then I would have more
sympathy to the way it has been designed.  There are many examples
of doing that in practice, though none of them are called standards.
However, that is not what is specified, that is not what browsers are
implementing, and that is not what network managers will soon see
on their monitors.