- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 4 Sep 2015 17:04:32 +0200
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org, The IESG <iesg@ietf.org>, Mark Nottingham <mnot@pobox.com>
On 2015-09-03 11:47, Stephen Farrell wrote: > ... >>> But more importantly, yes, I'm asking about the kind of analysis >>> that lead to the section 10.6 you point at. >> >> There was no analysis because the use of compression in this >> client->server direction really really isn't new at all. > > Hmmm. > > S. Right now we have: > 6. Security Considerations > > This specification does not introduce any new security considerations beyond those discussed in Section 9 of [RFC7231]. ...so that's clearly not helping. How about: "This specification introduces only discovery of supported content codings and diagnostics for requests failing due to unsupported content codings. As such, it doesn't introduce any new security considerations over those already present in HTTP/1.1 (see Section 9 of [RFC7231]) and HTTP/2 (Section 10 of [RFC7540]). However, the point of better discoverability and diagnostics is to make it easier to use content codings in requests. This might lead to increased usage of compression codings such as gzip (Section 4.2.3 of [RFC7230]), which, when used over a secure channel, can be subject to compression side-channel attacks such as BREACH (Section 10.6 of [RFC7540], [BREACH]). At the time of publication, it was unclear how BREACH-like attacks can be applied to compression in HTTP requests." Best regards, Julian
Received on Friday, 4 September 2015 15:05:07 UTC