- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Fri, 4 Sep 2015 16:29:55 +0100
- To: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>
- Cc: Mark Nottingham <mnot@pobox.com>, ietf-http-wg@w3.org, The IESG <iesg@ietf.org>
Hi Julian, That change would be great thanks, S. On 04/09/15 16:04, Julian Reschke wrote: > 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:30:27 UTC