RE: #466 segment compression

On 29 April 2014 21:57, grmocg@gmail.com wrote:
> If compression is per-segment as opposed to per-frame
>    AND we wish to restrict the amount of state the server must keep around
>    AND the sender wishes to have all the data in the segment compressed
>   THEN then the segment being compressed must be sent in its entirety in a contiguous series of frames with > no muxing of other streams in the middle.

The exact same problem exists for dynamic compression with C-E.  How are you going to solve that?


> I'm still worried: There is an assumption here that the originator of the stream actually knows the provenance

> of the various data within. This is often a hard problem especially given that servers and services are not

> currently architected to keep track of provenance. IMHO, if a segment/frame wasn't compressed it should

> never be compressed. That leads to safety.

I still don't understand this security argument with respect to intermediaries being able to add compression. I'm probably missing something.  Please enlighten me.



Compression is only a concern within TLS, right (e.g. BREACH etc.)? So...

1. If TLS is end-to-end, intermediaries can't touch anything anyway because they just see encrypted data.

2. If the TLS starts at a forward proxy, the proxy could change the compression when the data come out of the encryption tunnel before sending the data back to the client.  But at that point there is no security anyway.

3. If the TLS ends at a reverse proxy... this is the only potential problem I could think of because the intermediary could add compression "without provenance" before the data enter the tunnel.  But the reverse proxy by definition already has a relationship with the server, right? So the configuration should be set up such that the reverse proxy doesn't add compression.

4. If there is a break in the TLS somewhere in the middle?  That's not secure by definition.



> If the proposal is simply that if any frame in a segment is compressed all of something in a
> segment can be compressed, sure. I'm on board with that.

Yes, that's what I was saying - if we stick with frame-by-frame compression.


On Tue, Apr 29, 2014 at 1:41 AM, <K.Morgan@iaea.org> wrote:

I think the simplest idea is to require the origin to separate attacker-controlled data and private/confidential data by segments.  All of the rest of the intermediary problems go away since an intermediary already can’t re-frame across segment boundaries, plus it allows an intermediary to do whatever it wants within a segment (compress/uncompress/concatenate/de-compress+re-compress).

The thing I like about Martin’s idea to switch to one compression context per segment is that it provides greater compatibility between HTTP/1.x T-E and HTTP/2 transfer codings.  Per-frame compression as we have it now is compatible with T-E when going from 2 -> 1.x, but it’s not compatible from 1.x -> 2.  The added complexity and the “vast increase in DoS surface area” [1] is a big deal though.

[1] https://github.com/http2/http2-spec/issues/466#issuecomment-41361711

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 Thursday, 1 May 2014 22:02:04 UTC