- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Wed, 22 May 2019 08:35:31 +1000
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: Felipe Gasper <felipe@felipegasper.com>, Alan Egerton <eggyal@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, 22 May 2019 at 04:07, Patrick McManus <mcmanus@ducksong.com> wrote: > > The stream compression contexts are independent - which hurts compression ratios. However, the WG has not been able to find a satisfactory security answer to concerns around CRIME like attacks on TLS that sharing attacker controlled compression streams would enable. Progress on that front would be great. > > -Patrick > Yeah, this. The transport layer can not decide whether it's safe to compress *things* together, if those *things* aren't under its control. Since it's the application layer (or higher) that, in theory, knows the providence and security characteristics and everything else about the streams' data, it is the only layer than can decide whether or not to compress them. Which is why we can serve statically-compressed resources with content-encoding (application layer), and got rid of transfer-encoding (transport layer). If you wanted to provide hooks into the transport layer so that an application can explicitly say "these two streams are safe to share a compression context", and then trust that everyone running said application understands the security consequences, that could be a way forward. But if you have to guarantee that streams are processed in order for the shared context to work, how is that better than concatenating them in the same stream? Cheers -- Matthew Kerwin https://matthew.kerwin.net.au/
Received on Tuesday, 21 May 2019 22:36:05 UTC