On Sun, Oct 4, 2015 at 4:01 PM, Jeffrey Walton <noloa...@gmail.com> wrote: >>> 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. >> > I think two concepts are blending into one.... You appear to be > arguing for efficiency, and I'm more concerned with safely/securely. > > I'm fairly certain the internet community at large would benefit from > "compression done safely/securely", even if its not the most > efficient. If the application layer wants to provide a more efficient > implementations, then that's fine too. > > I think this I where things now stand (if I am surveying correctly): > (1) TLS WG did not fix the problem (bad); (2) users don't have a > choice (bad); (3) applications will have to provide their own > compression when desired, which will likely increase overall risk for > users (bad). For (3) keep in mind browsers are not the only user > agents or consumers of web services. > > All-in-all, I think its a win for NSA, GCHQ and other miscreants; and > an overall loss for user.
As we've tried to explain to you, TLS is a channel encryption abstraction, and does not know which parts of the stream of bytes it is being asked to send are controlled by who. Absent this information, there is no way to know what can be compressed how. By contrast applications know this information, and can design the compression scheme accordingly. How does this increase risk over TLS providing an inappropriate scheme which isn't secure? > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
