It seems to me that if this is a valid threat model, then all software is
potentially vulnerable.
TLS records are carried over TCP segments. What if an attacker can change
the way records are divided into segments, and thereby trigger a bug in the
record parser?
On Fri, Apr 20, 2018 at 9:40 AM, Victor Vasiliev wrote:
> 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 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
