W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: New Version Notification for draft-snell-httpbis-keynego-01.txt

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 19 Nov 2013 20:56:35 -0800
Message-ID: <CAP+FsNc5i=wZ=qLTFCNau3v9EbzxZgZGyoqPEb7P84MdqxBGJQ@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Yea, I mean BREACH.
When the framing is in the clear, one cannot hide the fact that one is
adding padding, and/or how much.
Having the bytestream be opaque allows the server/client to add padding and
thus at least linearly increase the amount of effort needed to verify a
hypothesis against a compression context.

On Tue, Nov 19, 2013 at 8:30 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Tue, Nov 19, 2013 at 05:03:35PM -0800, Roberto Peon wrote:
> > reducing jitter and increasing throughput/goodput. Exposing the
> > framing/length of things that would be in an encrypted-by-TLS bytestream
> > today, however, does worry me-- it makes BEAST/CRIME-like attacks
> > significantly more difficult to protect against.
> You mean BREACH/CRIME (the two attacks exploiting compression), right?
> BEAST was bad use of CBC mode and has seemingly nothing to do with
> compression.
> Also, I don't think even HTTP/2.0 style muxing would help with
> adaptive compression attacks (like BREACH and CRIME) unless the
> target site is being actively used.
> -Ilari
Received on Wednesday, 20 November 2013 04:57:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC