Re: [TLS] adopted: draft-ghedini-tls-certificate-compression

[Dave Garrett <[e-mail]>]

On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote:
> > Additionally, there's one bit of the spec which I question the need for: zlib support. Unless someone can show a legitimate case where zlib will consistently and notably outperform brotli, I don't see the point in defining it as an option. This is a bran new extension; we don't need backwards compatibility here. There's been a general consensus in this WG to avoid algorithm agility unless there's a real reason for it, so I propose we ditch zlib support and make brotli the default and only specified at the start (promoting it to id 0). Should some problem arise in the future where we actually need to use a decades old compression algorithm, it can be added later. Furthermore, we should probably define a pre-defined dictionary for brotli to use here which is based on common strings in certificates, rather than its default one for the general web (if such a thing is practical to do here). This could boost efficiency here and make it even more worth preferring (also likely reducing the size of said dictionary, as the default one is 120kB).
> 
> To play devil's advocate, why do suggest we ditch zlib and not Brotli?
> 
> I just did an experiment using certificate chains for facebook.com
> (ECDSA) and google.com (RSA).
> 
[...snip...]
> 
> As you can see, at level 1, Brotli is easily outperformed by gzip with
> and without dictionary, at level 6, both are basically the same, and
> at level 9/Z, Brotli wins by a small margin in terms of file size.
> 
> However, you need to keep in mind that Brotli has significantly higher
> cost of compression, both in terms of CPU and memory allocations
> (>40MB at higher levels), which might be unacceptable in some
> environments.
> 
> Don't get me wrong, I'm a big fan of Brotli, but unless we want to
> squeeze every single byte out of the compression and/or use
> pre-compressed certificates, then maybe Brotli isn't the best and only
> choice here?

This is a convincing argument to me. Thanks for the data. Given this information, I agree that supporting both algorithms can be helpful here, depending on server hardware constraints.

I'm still curious to know if we can potentially create a lightweight cert-specific dictionary here that can boost things a bit. Or, is the QUIC one largely based on certs too?

As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give us any useful gains here over zlib, even with a new dict, I'd be ok with not specifying it for use. Your test does show it getting a small win at max compression, so that may not be the case. After fiddling with defining a new dict, test data against a larger set of certs could be useful.


Dave