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

[Piotr Sikora <[e-mail]>]

Hey Dave,

> 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).

I compressed them with Brotli (at levels: 1, 6, 9 and 11 - aka Z) and
gzip (at levels: 1, 6 and 9):

facebook.com-ecdsa-chain.pem 4485 (222%)
facebook.com-ecdsa-chain.der 2024 (100%)

facebook.com-ecdsa-chain.br1 1823 (90%)
facebook.com-ecdsa-chain.br6 1673 (83%)
facebook.com-ecdsa-chain.br9 1644 (81%)
facebook.com-ecdsa-chain.brZ 1597 (79%)

facebook.com-ecdsa-chain.gz1 1699 (84%)
facebook.com-ecdsa-chain.gz6 1687 (83%)
facebook.com-ecdsa-chain.gz9 1687 (83%)

google.com-rsa-chain.pem 5749 (266%)
google.com-rsa-chain.der 2160 (100%)

google.com-rsa-chain.br1 1541 (71%)
google.com-rsa-chain.br6 1343 (62%)
google.com-rsa-chain.br9 1348 (62%)
google.com-rsa-chain.brZ 1330 (62%)

google.com-rsa-chain.gz1 1434 (66%)
google.com-rsa-chain.gz6 1398 (65%)
google.com-rsa-chain.gz9 1398 (65%)

Then, I did the same using pre-defined dictionary from QUIC Crypto:

facebook.com-ecdsa-chain.bq1 1823 (90%)
facebook.com-ecdsa-chain.bq6 1505 (74%)
facebook.com-ecdsa-chain.bq9 1482 (73%)
facebook.com-ecdsa-chain.bqZ 1460 (72%)

facebook.com-ecdsa-chain.gq1 1536 (76%)
facebook.com-ecdsa-chain.gq6 1506 (74%)
facebook.com-ecdsa-chain.gq9 1506 (74%)

google.com-rsa-chain.bq1 1541 (71%)
google.com-rsa-chain.bq6 1248 (58%)
google.com-rsa-chain.bq9 1239 (57%)
google.com-rsa-chain.bqZ 1233 (57%)

google.com-rsa-chain.gq1 1317 (61%)
google.com-rsa-chain.gq6 1266 (59%)
google.com-rsa-chain.gq9 1266 (59%)

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?

Best regards,
Piotr Sikora