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

Stephen Farrell <> Tue, 06 September 2011 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1A2A21F8F1A; Tue, 6 Sep 2011 14:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TLzaGw85Tfj0; Tue, 6 Sep 2011 14:46:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A3EEB21F8F09; Tue, 6 Sep 2011 14:45:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3775153593; Tue, 6 Sep 2011 22:47:20 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1315345640; bh=orgwIOGCEai9cl 5oDQqdPLYaAO0jIfwqQts4Y84qEaI=; b=usje4xafM2RT9DJ6ZkZTbdmYioEfnd Itsn9cb/McmsasboT7XGVIVN1k1iXmd6LTLnLanUYEVWwp00hGi+g+wtzhukYZAI KgWOGqgXPz23m7m2WdECN6ZMrKFsftner9yOaye+21VbDdZsGTHX7gN+GeAJyaOL SzdC6wBEsCMOsjstmDrMolZgD3nim91QKaOIGoZ2eGIkN4gXYGcmDRdpv8/WGmPr kPxKKUPNb+rL1pmgv9HAGUlKWnsGsS5ztpw8+WXgwQJ+BTi08np+kisVHnc6FOnq UFLoh5+DpRpxQCwj4WJPzq8tK0klTkoVoXyZ6MCG9LlG97OPxye+DV8Q==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id mbEGXX6cMoTk; Tue, 6 Sep 2011 22:47:20 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 9767C15358D; Tue, 6 Sep 2011 22:47:19 +0100 (IST)
Message-ID: <>
Date: Tue, 06 Sep 2011 22:47:19 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: "Richard L. Barnes" <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 06 Sep 2011 14:51:30 -0700
Cc: Server-Initiated HTTP <>,, "Roy T. Fielding" <>,
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 21:46:02 -0000

On 09/06/2011 10:36 PM, Richard L. Barnes wrote:
>> On 09/06/2011 06:57 PM, Richard L. Barnes wrote:
>>> IMO, this is a pretty strong argument against masking, given how low the observed rate of buggy intermediaries is (~0.0017%) and how high the observed rate of malware propagation is.
>> I'm not sure what you're comparing there. Can you elaborate?
> Sorry, should have provided references.  The observed rate of cache poisoning vulnerability is from the "Talking to Yourself for Fun and Profit" paper.  They did an empirical study (using an ad buy) of several variants of the WebSocket protocol.  They found 8 users vulnerable out of around 54,526 tested. So I actually had my math a bit wrong, the prevalence is more like 0.015%.
> <>

Right. One of my discuss points on this was that they
need to reference.

> It's worth noting, though, that their experiment used an older version of the protocol (-03 at the latest), and is not compliant with whichever version they used.  In particular, they omit the data framing header.  Since these octets seem unlikely to increase the probability of a proxy accepting a poisoning request, I would regard their number as an upper bound on the prevalence of buggy proxies.
> Another interesting finding in that paper was that there were no observed instances of a CONNECT-based variant of the protocol successfully poisoning proxies (on the same sample set of ~54k users).  This might lead one to think that the problem that masking solves could also be avoided by using HTTP differently.  I think that this option was discussed in the WG and decided against, but I don't know why.
>> In fact, I'm not sure I get the malware argument. Malware
>> authors are also free to obfuscate or mask their stuff,
>> when both sides of the conversation but not the intermediaries
>> are controlled as would be the case here. Or maybe I'm
>> missing something?
> It's a question of how many layers of obfuscation the firewall has to manage.  Malware scanners have to deal with polymorphism already today, and there are lots of approaches, so that's not really an is.  Masking is a layer on top that the firewall would have to unwrap.  Just as with 6to4, in principle, masking is just an annoyance, another thing to decapsulate.  In practice, firewalls have not kept up with these things, so requiring masking on WebSockets is likely to create a reasonably long-lived channel for circumventing firewalls.

Ok. Thanks.

>> I personally think the masking thing is pretty ugly. But I
>> have to (reluctantly) admit I think it does what its
>> supposed to do. At this stage I think it comes down to
>> either doing the masking or not using port 80.
> I'm sort of of the same feeling.  I don't disagree that masking solves the problem it sets out to.  The question is whether there are other ways to solve the problem that are simpler, with fewer side effects.

Fair enough. I think what you're saying is we can go with
masking, or revisit what the WG decided (masking) in
reaction to the above-cited paper, or else get them off
port 80.

Pragmatism is certainly pushing us towards the first of


> --Richard