RE: Transfer-codings, mandatory content-coding support and intermediaries

Hi Martin-



On Monday,21 April 2014 22:20, Martin Thomson wrote:
> On 21 April 2014 12:47,  <K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>> wrote:

>> But regardless, at a minimum the security considerations of compression without proper context should be explicitly enumerated.

>

> Can you tell me exactly how this [1] falls short?

> [1] http://http2.github.io/http2-spec/#rfc.section.10.6




Section 10.6 "Use of Compression" says "Compression MUST NOT be used if the source of data cannot be reliably determined."  Admittedly, if you read between the lines, this basically says intermediaries should never add compression because they likely know nothing about the data and their source. My suggestion was to state it more explicitly.



For example, in the very next section (10.7 "Use of Padding"), the final statement is...

"Intermediaries SHOULD NOT remove padding, though an intermediary MAY remove padding and add differing amounts if the intent is to improve the protections padding affords."



I was suggesting adding a similar statement, but directly in the section describing the DATA frame gzip flag (i.e. Matthew’s PR), because intermediaries should never add/remove C-E compression IMO.

“Intermediaries SHOULD NOT add gzip compression, though an intermediary MAY remove gzip compression, particularly if disabling compression might mitigate attacks that rely on compression*. Intermediaries MAY also remove and then re-apply gzip compression if necessary, e.g. to extract a range.”



*for example, if an intermediary is forwarding compressed plain text traffic from an origin server to a TLS tunnel



I don’t care that much though so I’m done bringing it up :)



-keith



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Tuesday, 22 April 2014 07:50:20 UTC