> On 20 May 2024, at 23:37, Robert Haas <robertmhaas@gmail.com> wrote: > > But, does this mean that we should just refuse to offer compression as > a feature?
No, absolutely, we need the feature.
> I guess I don't understand why TLS removed > support for encryption entirely instead of disclaiming its use in some > appropriate way.
I think, the scope of TLS is too broad. HTTPS in turn has a compression. But AFAIK it never compress headers. IMO we should try to avoid compressing authentication information.
That used to be the case in HTTP/1. But header compression was one of the headline features of HTTP/2, which isn't exactly new anymore. But there's a special algorithm, HPACK, for it. And then http/3 uses QPACK. Cloudflare has a pretty decent blog post explaining why and how: https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/, or rfc7541 for all the details.
tl;dr; is yes, let's be careful not to expose headers to a CRIME-style attack. And I doubt our connections has as much to gain by compressing "header style" fields as http, so we are probably better off just not compressing those parts.