Subject: Re: [TLS] potential attack on TLS cert compression

From: Victor Vasiliev <[email-masked]>
Date: Thu, 19 Apr 2018 14:40:48 -0700

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 <[email-masked]> 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.

---

From: Alex C <[email-masked]>
Date: Sat, 21 Apr 2018 11:46:41 +1200

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 <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Apr 2018 23:48:14 +0000

*   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?

Why do you think this is possible?  The sizse of the record is part of what’s secured.