RE: #466 segment compression

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




--
Keith S. Morgan
Remote Monitoring Unit
Safeguards, International Atomic Energy Agency (IAEA)
Vienna, Austria
Office: +43 1 2600 26672
Handy: +43 699 165 26672

From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of matthew@kerwin.net.au
Sent: Tuesday,29 April 2014 08:53
To: ietf-http-wg@w3.org
Cc: Martin Thomson
Subject: Re: #466 segment compression

Sorry for replying to myself.

On 29 April 2014 16:26, Matthew Kerwin <matthew@kerwin.net.au<mailto:matthew@kerwin.net.au>> wrote:
All three operations (determining frame length, compressing frames, and padding) are hop-by-hop operations, and any intermediary can second-guess or obstinately undo the previous hop's choices if it wants.


​I just noticed the ​bit in 10.6 that says that intermediaries can't add compression. Is that the delineation to which you referred in #466 Martin?  That text introduces complexity I hadn't imagined when proposing per-frame compression. I'll think about it some more.


--
  Matthew Kerwin
  http://matthew.kerwin.net.au/


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.