Re: Negotiating compression

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

Roland


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 
<http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-07#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 ?
>