Re: Compression and zstd licensing update

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Certainly not for transport, I fully agree.

But some application level protocols do need compression - in the extreme
you would not send images in RAW format. I do not have a good answer to the
risks of compression other than ensuring padding up to a certain block size
and avoid compressing very sensitive data. Have applications protocols
handling this might be safer than having leaving it to arbitrary
pre-compression fed into the com channel.

Regardless, I’m not advocating adding compression, only highlighting that
wherever compression is deemed relevant, zstd is now a more approachable
option.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 2 October 2017 at 16.54.05, Eric Rescorla ([e-mail]) wrote:

I would not be in favor of including any compression of the plaintext in
QUIC. We already know that compression + encryption is dangerous, which is
why we removed it from TLS 1.3.

-Ekr


On Mon, Oct 2, 2017 at 2:20 AM, Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> FYI:
>
> I have just gotten confirmation by the author that Facebooks zstd
> compression library is now a pure BSD license without PATENTS protection
> claims which Facebook also removed from ReactJS and graphQL.
>
> This means that zstd it could be a viable compression technology, for
> example in QUIC/HTTP - though I haven’t followed the HTTP efforts closely.
>
> zstd appears to have the best tradeoff in terms of
> cost/bandwidth/computation effort while I personally would use LZ4 for some
> performance critical applications to due raw speed where bandwidth is
> sufficient.
>
>
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>