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

Joel Martin <> Sat, 03 September 2011 18:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A58A021F8AFB; Sat, 3 Sep 2011 11:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n9cZs2GaKhAH; Sat, 3 Sep 2011 11:50:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ECC0721F8B0B; Sat, 3 Sep 2011 11:50:25 -0700 (PDT)
Received: by fxe6 with SMTP id 6so2730331fxe.31 for <multiple recipients>; Sat, 03 Sep 2011 11:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ccElJMAhH/7/XRGWzVYNuBnd7/+vKQYAP1FP3Y+5tcc=; b=Noel/q9KtXoGsa4QMzjcNpC0WYpK1xu33ca61aIlwEcXJCCJApROPDHEaktML9e0SK ufDJ8a4CrjIGEHrCbQ5AnXHdAzo7OBI8xaK03nuKqYJ2DTZoSToJClJQ5qnqmhcNFegE gSJ9hXZek/8mwkKqP8JKFHqa6Xdxwlh6mJmAw=
Received: by with SMTP id 27mr2358483fav.90.1315075924106; Sat, 03 Sep 2011 11:52:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 3 Sep 2011 11:51:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Joel Martin <>
Date: Sat, 3 Sep 2011 13:51:44 -0500
X-Google-Sender-Auth: ROnoxqjouf0mD7vTvXn7qhgEn0k
Message-ID: <>
To: "Roy T. Fielding" <>
Content-Type: multipart/alternative; boundary=00151747b4c24f1f9b04ac0df985
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: Sat, 03 Sep 2011 18:50:30 -0000


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.

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

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:

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.


Joel Martin

On Sat, Sep 3, 2011 at 12:03 PM, Roy T. Fielding <> wrote:

> I don't know if this is a cultural issue or not, but neither of those
> changes is an improvement, nor should they be any less offensive.
> Convoluted and inefficient describes the hashing algorithm in the
> least offensive way possible -- "complex" doesn't say anything.
> There are a lot of complex algorithms (e.g., TLS) that are
> necessarily so.
> And I gave the sole reason the WG has for using those ports -- I don't
> want people to imagine there might be any other (sane, unselfish, etc.)
> reasons.
> Besides, what I wrote is entirely factual -- the offensive version
> would have melted your LCD.
> ....Roy
> On Sep 3, 2011, at 6:17 AM, Julian Reschke wrote:
> > On 2011-09-03 12:54, Julian Reschke wrote:
> >> Hi,
> >>
> >> I believe that almost everything Roy says below is non-controversial; if
> >> we can tune the language to be less offensive it might fit well into the
> >> Introduction (and not require an IESG Note to get into the document).
> >>
> >> Best regards, Julian
> >> ...
> >
> > Like that...:
> >
> >   The WebSocket protocol is designed with an assumption that
> >   TCP port 80 or 443 will be used for the sake of tunneling raw
> >   socket exchanges over HTTP.  The result is a convoluted and
> >   inefficient exchange of hashed data for the sake of bypassing
> >
> > s/convoluted and inefficient/complex/
> >
> >   intermediaries that may be routing, authenticating, filtering,
> >   or verifying traffic on those ports.  The sole reason for using
> >
> > s/sole//
> >
> >   ports 80 and 443, and hence requiring the hashed data exchange,
> >   is because many organizations use TCP port blocking at firewalls
> >   to prevent unexpected network traffic, but allow the HTTP ports
> >   to remain open because they are expected to be used for normal
> >   Web request traffic.  WebSocket deliberately bypasses network
> >   management constraints in order to enable Web application
> >   developers to send arbitrary data though a trusted port.
> >
> >   Naturally, the WebSocket protocol does not have the same network
> >   characteristics as HTTP.  The messages exchanged are likely to
> >   be smaller, more interactive, and delivered asynchronously over
> >   a long-lived connection.  Unfortunately, those are the same
> >   characteristics of typical denial-of-service attacks over HTTP.
> >   Organizations deploying WebSockets should be aware that existing
> >   network equipment or software monitoring on those ports may need
> >   to be updated or replaced.
> >
> > Best regards, Julian
> > _______________________________________________
> > hybi mailing list
> >
> >
> _______________________________________________
> hybi mailing list