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

On 21 April 2014 15:13, Matthew Kerwin wrote:
> On 21 April 2014 22:22, <K.Morgan@iaea.org> wrote:
>
> On 19 April 2014 21:54, MORGAN, Keith Shearl wrote:
>> I suggest something like the following...
>>
>> Intermediaries MUST NOT add GZIP compression to a DATA frame. Intermediaries MAY
>> remove GZIP compression frome DATA frames if necessary. Intermediaries MAY also
>> remove and re-apply GZIP compression, so long as all compressed data were
>> originally compressed by the origin.
>> ...
>
> It's too hard to enforce that MUST NOT; it's quite likely to become an RFC 6916-style "MUST NOT
> (BUT WE KNOW YOU WILL)"​. Or put more politely: if someone implemented it by mistake, how would
> anyone ever detect it?

Thanks for the response.  Do all MUST-level requirements have to be enforceable? (If so, I didn't know that.)

Would it work to replace MUST NOT with SHOULD NOT?  (SHOULD NOT isn't enforceable by definition right?)

At the very least, please add some sort of "security considerations" for transfer/frame layer compression, particularly with respect to intermediaries.

(IMO, the right way to enforce a lot of this would be signing unmodifiable headers etc. by the origin. I guess that will have to wait for HTTP/3 though.)


> An alternative which I'm starting to imagine might be to use END_SEGMENT to delineate secret data and
> potentially-attacker-supplied data; ...

I'm not sure exactly how you would implement that, but I imagine it would get very complicated in a hurry.
Besides, I still don't see how you could enforce any requirements that intermediaries don't add compression.
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 Monday, 21 April 2014 18:11:42 UTC