Re: [TLS] potential attack on TLS cert compression

[Victor Vasiliev <[e-mail]>]

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 <[e-mail]> 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.