Re: [TLS] TLS 1.3 - Support for compression to be removed

[Eric Rescorla <[e-mail]>]

On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>