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

On Wed, Jun 7, 2017 at 5:43 PM, Dave Garrett <davemgarrett@gmail.com> wrote:

> 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 t
>  he 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.
>

I'm not sure what units we are measuring in here: 222% of what? And what
exactly is wrong with special formats that be much more compact on embedded
devices, or enabling point compression?

If you want root+intermediate+leaf that's 224 bytes of keys and signatures.
Being sparing in extra data can probably have <300 byte chains, without the
CPU overhead of compression at the cost of compatibility.

>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.