Re: Security implications of gzip #423

Martin,

You have done a good job of walking the line between explaining the attack
and that rational for the mediation concisely.  I have a couple of thoughts
on the last, implementations, paragraph.

The following statement is indirect and it 'may' clear what "every time"
means: "Thus, even though gzip compression of response bodies is permitted
for every response, it cannot be used every time.". For example, how
about, "Accordingly,
do not use gzip compression of the response body in this scenario".

I would also add that MUST NOT should really be testable for
compliance/conformance purposes.  Since HTTP does not define confidential
or attackers I think SHOULD NOT makes more sense for that statement.  Or
one might consider moving the MUST NOT to the next sentence.
Possible alternatives, "Thus, gzip compression of response bodies are
permitted for any response but MUST NOT be it cannot be always used." or
"Accordingly, implementations MUST NOT force the use gzip compression for
all response bodies"  (Might choose the word every over all)

Less important thought, the client system can in many situations be
responsible for the security of the information as well.  Think about
utility services that may not understand the sensitivity of the information
they hold or what constitutes an attacker.  The client/requestor might
actually hold the meta-data to know if a resource is confidential.  Is it
worth a mention that the accept-encoding by the consumer might inform the
appropriate encoding for the response for exactly these types of scenarios?
 I would imagine that accept-encoding (at least in revision ten) will be
used less frequently anyhow and would represent a more exceptional scenario.

Regards,
Ted


On Thu, Mar 13, 2014 at 8:58 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Proposed text:
>
>    HTTP/2 enables greater use of compression for both header fields
>    (Section 4.3) and response bodies (Section 9.3).  Compression can
>    allow an attacker to recover plaintext when plaintext under attacker
>    control is compressed in the same context with secret data.
>
>    There are demonstrable attacks on compression that exploit the
>    characteristics of the web platform (e.g., [BREACH]).  The attacker
>    induces multiple requests containing varying plaintext, observing the
>    length of the resulting ciphertext in each, which reveals a shorter
>    length when a guess about the secret is correct.
>
>    Implementations MUST NOT compress plaintext that includes content
>    from both confidential and potentially attacker-controlled sources in
>    the same compression context.  Thus, even though gzip compression of
>    response bodies is permitted for every response, it cannot be used
>    every time.  An implementation MAY compress confidential and
>    potentially attacker-controlled content independently, if such
>    content can be reliably distinguished.
>
>    Further considerations regarding the compression of header fields are
>    described in [COMPRESSION].
>
> http://http2.github.io/http2-spec/#rfc.section.10.6
>
>