I want to thank a lot Patrick for the initiative of this straw poll.


as chair I have to say that I share the same Patrick's feeling:
after a tons of mails I haven't seen a lot of mind being changed!


having said that, I think it is really time to check
"/where we can put the bar of an acceptable and good web sockets protocol/",
or if you prefer it expressed in an IETF style
*where/on which proposal we can reach the rough consensus*

In the sake of making progress,
I would change the poll, generalizing it on an approach based on
"GET+Upgrade containing mandatory client-server masking"

let the decision of what kind of mask to use for a next step/poll.
(as well as the hello/Greg point)

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com






On 12/22/10 6:25 PM, Pat McManus @Mozilla wrote:
> Hi all,
>
> Like everyone else I am looking for a way forward that gives us a good
> protocol with wide acceptance soon. It doesn't have to be the best
> protocol and if "wide acceptance" is our goal it is unlikely a wide
> group would agree on the definition of "best" anyhow. It should go
> without saying that wide != universal.
>
> With that in mind I want to ask everyone if they think an approach based
> on Get+Upgrade containing mandatory client->server XOR masking meets the
> bar of an acceptable and good web sockets protocol.
>
> Maybe you think that a CONNECT based approach is marginally better (I
> personally do, btw), or an all TLS-NPN approach is best, or using a
> different port and abandoning HTTP semantics is the best way to go.. but
> that's not my question here - all of those things have pretty severe
> objections lodged against them that weigh them down. We already know
> unofficially from just reading the archives that there isn't consensus
> around their suitability at this time and I don't see a lot of minds
> being changed as a result of all the email.
>
> So my question is does the upgrade-with-unidirectional-xor-mask meet
> your bar for "I could live with that". Saying yes doesn't mean that you
> will be called a hypocrite for supporting something else with a higher
> preference.
>
> I have just reread the last month's worth of archives and I am aware of
> one point of view that thinks the mask is just too expensive to be
> worthwhile and I was (surprisingly to me) unable to find any other
> fundamental objections although several folks did note there are costs
> involved. I am not claiming I found a lot of explicit support either,
> just that the path seems to clear to ask this question.
>
> Let me make the pitch:
>
> * The approach is HTTP spec friendly and routable.
> * It is intermediary friendly in the sense that it is a plaintext
> equivalent and interacts with HTTP upgrade in the expected manner.
> Obviously changes need to be made in the way Upgrade envisioned.
> * It acknowledges that any known handshake might still have issues with
> intermediaries inspecting the data path and being exposed to
> poison/spoofing attacks but it secures the data path against that with a
> relatively low cost masking.
> * it does not have dependencies on other specs, deployments, etc
> * it does not have potential issues with regulatory compliance whether
> those issues are externally (licenses, etc..) or internally (legal
> review) imposed.
> * It accomplishes this at reasonable cost
>    + masking is unidirectional and favors the server end. I've worked on
> servers in the past and right now I'm working on a browser and I really
> do believe that is the right trade off. A browser is much more
> interested in latency than in overall load scaling, while a server has
> real concerns about the latter. making sendfile() useless to the browser
> is no big deal - it doesn't help with latency when compared to IP time
> scales and the client is less likely to have the kind of data that would
> be zero copied anyhow.
>    + XOR in place for something that is already sitting in memory is a
> trivial cost in terms of CPU and essentially a zero cost in terms of
> memory, so it is suitable for low level embedded clients.
>
> I want to acknowledge that I think the biggest downside here is actually
> the expanded framing cost of including the key on every frame -
> especially in the case of mobile agents sending frames using the 0-125
> byte payloads in order to save transmission power. This will be a
> significant tax on that use case, but given the overall situation, the
> benefits of this proposal, and the relative nicheness of that
> requirement I can swallow that tax and live with it in good conscience.
>
> The other thing worth noting is that that I went the XOR route instead
> of AES here. We've had a number of objections to AES based on
> compliance, bundling, and to a lesser degree performance. The
> explanation on list for favoring AES deals with an attacker being able
> to control the relationship between bytes in the data stream but not
> their actual values - no one has suggested a vector by which this is a
> problem for our non-cryptographic goal. But if your objection to
> get-upgrade-with-unidirectional-xor is that it requires AES to meet a
> level of "that's acceptable to me" (not just better), please do state
> that explicitly and as a favor to me help explain what the exposure is.
>
> -Patrick
>
> (I haven't mentioned hello - greg points out that it has value
> independent of the handshake/mask and I therefore simply want to treat
> it independently.)