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

-- 
http://www.getfirefox.com/