Did we ever reach any agreement about what to do here? For me, the threat model here seems fairly far-fetched and infeasible, in the sense that the threat only exists in some very specific bugs in multithreaded decompressor.
I'd be less reluctant to do this if it were not for the fact that all solutions I've considered for this are quite annoying. Putting the hash on the wire means wasting bytes, and altering the transcript hash introduces a lot of complexity into some implementations. On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin <por...@bolet.org> wrote: > > Certificate compression would be challenging to implement, though. > Usually, compression relies on at least a "window" over the decompressed > data (32 kB for Zlib/Deflate). Some rudimentary forms of compression > don't need that (e.g. run-length encoding) but usually offer poor > compression ratios. A 32 kB window is a lot for the kind of architecture > that BearSSL targets. > This is roughly my intuition -- you could parse certificate messages in a streaming manner, but if you're on a sufficiently limited platform that this is a worthwhile investment, you're probably not going to use certificate compression anyways.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
