RE: h2#404 requiring gzip and/or deflate

On Fri, 21 Feb 2014 11:16:21, Martin Thomson wrote:

> On 21 February 2014 11:02, Albert Lunde <atlunde@panix.com> wrote:

>> Another question is whether compression schemes introduce side channels better to attack TLS.

> Yes, there is a concern here.  That's why we have padding. ...

> If at some point [our TLS friends] come to us and say "we have decided to forbid compression" or,

> more likely, "you are going to have to do the following things if you

> want to use compression", then we will have to consider our options.



As Albert mentioned, suppose a side-channel attack of TLS is found (particularly in light of CRIME, BREACH, etc.) and suppose (although unlikely) there are no options from "our TLS friends" other than to "forbid compression".

What are the options from the perspective of clients that may want to explicitly opt out of compression? The implicit "Accept-Encoding: gzip" leaves a client no way to tell the server to not use compression.

In other words, if an attack is found, you have to wait for all the servers around the world to be patched to manually disable compression.





On Saturday,22 March 2014 20:35, cory@lukasa.co.uk wrote:

>> On Friday,21 March 2014 22:40, Zhong Ju wrote:
>> What if the request has Accept-Encoding: gzip;q=0 Can server ignore that directive and send gzip-ed response anyway?

> The current draft leaves no way to prevent the server from sending you gzip.

> Of course, servers may _choose_ to honour your request, but they aren’t required to.



I think an implicit opt in for accept-encoding for gzip is no problem, but at the very least there should be a way for clients to explicitly opt out of gzip.



A few thoughts on options…



1. Zhong Ju’s idea to send "Accept-Encoding: gzip;q=0" seems like the most logical option, but q=0 support is definitely mixed at best (based on a simple random check of servers in the wild). I suppose explicit support for gzip;q=0 could potentially be mandated by language in the HTTP/2 RFC?



2. Sending any “Accept-Encoding” header explicitly overrides the implicit gzip value (admittedly I’m not sure of all the implications of this option).



3. Switch back to an explicit “opt-in” for compression.  Are the really that many clients out there that don’t already send “Accept-Encoding: gzip”?? (The overhead of using this header on every request should be minimal by adding it to the HPACK static table.)



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.