SPDY compression and CRIME attack

You may have read about the CRIME attack recently:

http://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor/19914#19914

http://www.cio.com/article/716161/_39_CRIME_39_Attack_Abuses_SSL_TLS_Data_Compression_Feature_to_Hijack_HTTPS_Sessions

Now that this public, we wanted to make the working group aware that SPDY
was vulnerable to this.  As of this writing, firefox and chrome have
already patched their SPDY implementations, so users running latest
versions are not exposed.  However, the current fixes reduce the
compression ratio that we get in SPDY headers.  I don't have perf metrics
comparing the two.  Overall HTTP/2.0 will want to just use a different
compressor.  But this was already desired by many for a number of reasons
and shouldn't have too much of an impact on the overall effort.

The basic problem is that if you use a single compression context to
compress both sensitive data (like a cookie) and user-controlled data (like
a query string), then this attack can be used to reverse engineer the
contents of a cookie, even when you're using SSL.  Note that the attacker
needs to be able to read your packets and also lure the victim to an attack
site to carry out this attack.

Several people have already been working on alternate compressors; many of
which would avoid this attack already.  Roberto Peon has been working on
one for SPDY/4 (this work started independently of this attack), and it has
several good properties, but is still in development:
   * compression levels better than SPDY/3's compressor
   * less CPU usage (faster)
   * less memory consumption
   * not vulnerable to the CRIME attack
   * https://github.com/grmocg/SPDY-Specification/tree/gh-pages/example_code

Mike