W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Negotiating compression

From: Roland Zink <roland@zinks.de>
Date: Wed, 28 May 2014 13:01:40 +0200
Message-ID: <5385C214.2030209@zinks.de>
To: ietf-http-wg@w3.org
Partly the responsibility if compression can be used is given to the 
applications. With a potential new API they may specify that some 
headers should not be compressed. So a plan B could be to always use 
this (or simply blame the application that they were not following the 


draft-ietf-httpbis-header-compression-07 in section 5.1. 
Compression-based Attacks:

HPACK enables an endpoint to indicate that a header field must never be 
compressed, across any hop up to the other endpoint (see Section 4.3.3 
An endpoint MUST use this feature to prevent the compression of any 
header field whose value contains a secret which could be put at risk by 
a brute-force attack.

On 28.05.2014 11:41, Simone Bordet wrote:
> Hi,
> On Tue, May 27, 2014 at 7:54 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> The long and rambling thread on schedule has again started to discuss
>> HPACK.  A point was made regarding negotiation for its use.
>> I don't think that negotiation is necessary.  The argument regarding
>> the physics, which would dictate the use of an entire RTT for
>> negotiation, is compelling, but I have others.  The only reason you
>> want negotiation is if you want to be able to influence the behaviour
>> of a counterparty.
>> A sizable advantage can be gained by modifying your own behaviour,
>> which HPACK always permits.  Given that the data you care most about
>> protecting is usually the stuff that you send, I'm willing to bet that
>> this is good enough in the unlikely event that an attack is
>> discovered.
> Can you please expand on what is plan B in the unlikely event ?
> I am guessing that it would require to bump the HTTP version, and a
> worldwide update of all servers to the new version (or drop to HTTP
> 1.1) ?
> Also, if a different, better, header compression algorithm is found,
> that also would require a HTTP version bump ?
> I'd really like to be as confident as you are, but I'd like to have a
> plan B for one of the most used protocols in the world.
> So far, IIUC, there is no plan B, right ?
Received on Wednesday, 28 May 2014 11:02:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC