On Sun, Oct 4, 2015 at 1: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. > The problem is that we don't know how to generically provide compression safely. To take a concrete example: HTTP2's solution to header compression, HPACK, is extremely limited compared to a generic compression system like gzip, LZ77, etc., as well as being tightly-coupled to HTTP, and yet we still know that there are potential security problems [0]. Doing something generically secure is much harder. If you have a solution to this problem, then great. But the mere fact that it's desirable doesn't mean we have an answer. -Ekr [0] Specifically, that the attacker can confirm specific guesses about the contents of a header field. > All-in-all, I think its a win for NSA, GCHQ and other miscreants; and > an overall loss for user. > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
