On Sunday, October 04, 2015 03:00:33 pm Tony Arcieri wrote: > On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > I can think of a way to do this, but the people who want compression badly > > probably won't like it due to the need to pad heavily. > > > > 1) Pick a fixed bandwidth > > 2) Compress & encrypt the stream > > 3) Send the compressed stream at a rate blocked to the cap > > 4) Whenever below the cap, pad the stream to the cap > > > > Maintain a fixed transmission of data per unit time and there's no way to > > tell the size of anything (even if delivery doesn't match the rate). > > This sounds like Constant Bitrate (CBR) compression, which works for > encrypted media (e.g. encrypted voice and video), but probably isn't > particularly useful outside the realm of realtime media. It was a solution > that seems to work for attacks that could e.g. transcribe encrypted phone > calls by studying patterns in Variable Bitrate (VBR) compression on speech. > > Typically compression is used to lower the overall size of data, working on > a wide class of inputs. In the perceptual coding case the class of inputs > is constrained, and the goal is to keep the data rate constant, not > optimally small.
Yep. You could do this in bursts with different caps each time to get it to work with bursty things like HTTP & other general data transfer protocols. Without a really good modern compression algorithm, though, it isn't that appealing. Once these caveats and tweaks start getting added to the simple concept, it starts treading into the territory that is better handled by the application protocol that actually *knows what it's sending*. This seems to be the logical wall we keep hitting, which is why TLS doesn't seem like the place to do this. Maybe some new transport protocol could be fed information to tell it how to handle compression safely, but TLS is not a transport protocol nor a young one that can be fundamentally changed to accommodate everything. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
