Subject: [TLS] TLV vs Compression

From: James Cloos <[email-masked]>
Date: Fri, 11 Jul 2014 21:36:53 -0400

My understanding is that tls with compression is vulnerable due to
allowing unauthenticated initiators, which permits an oracle attack.

If so, does it follow that a tls-like protocol, which enables
compression only when symetric key negotiation uses temporal secrets
(ie, the pfs concept), when mutual authentication is done, and only for
application-level data, would be safe from compression-specific attacks?

Or posed differently, if an application knows that the tls socket uses
pfs and is mutually authenticated, is it ever safe for *it* to compress
the data it sends over said socket?

And for sockets which are only half-authenticated, can it be secure for
the side which authenticated its peer to compress its own outgoing data?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 19:56:23 -0700

> the data it sends over said socket?

Tying this to authentication works only to the extent that the
authenticated actor is solely responsible for content.  The concern is
largely based on where the data comes from.  Attacks shared so far
[CRIME/BEAST] rely on compression that includes a mix of attacker
controlled content and content the attacker wants to learn about.

If you can guarantee single origin, then the length of an encrypted
packet can reveal information, but it's pretty low in signal.  An
attack might still be able to attack low entropy secrets that use
compression techniques that don't suit this use.  Besides,
guaranteeing that data is free from attacker influence is not that
easy to do.

The only technique that I think stands any chance here is to avoid
generic compression, and rely on content-aware compression mechanisms
that can be adjusted to deal with cases where content is controlled by
mutually distrustful actors.

Look here to the decisions made in HPACK, which is far worse than the
state of the art in terms of compression efficiency at best.  And
HPACK will rarely reach optimum compression in practice due to the
need for numerous safeguards against these sorts of attacks.