On Wednesday, June 07, 2017 01:38:59 am Raja ashok wrote: > So I suggest we should consider compression on client certificate message > also.
+1 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 s ize of said dictionary, as the default one is 120kB). Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
