Re: [secdir] secdir review of draft-alakuijala-brotli-08

Dear Daniel,
in my understanding this ID is _only_ about a compression, not about 
encryption.
Therefore it is not even intended to be resistant to the attack you 
describe below.
(for proper confidentiality the channel would need to be encrypted.)
Best regards, Tobias

On 11/04/16 17:19, Daniel Kahn Gillmor wrote:
> On Mon 2016-04-11 01:47:40 -0400, "Xialiang (Frank)" <frank.xialiang@huawei.com> wrote:
>> This document defines a lossless compressed data format that
>> compresses data using a combination of the LZ77 algorithm and Huffman
>> coding, with efficiency comparable to the best currently available
>> general-purpose compression methods.
>   [...]
>> In general, this document specify a new compressed data format which
>> is used in the end points of a connection, which is not directly
>> subject to network security issues. In other words, the compressed
>> contents can be protected by all the existing security technologies
>> (i.e., encryption, authentication/authorization, anti-attack, etc) if
>> necessary. The main security concern is about how the bad (or faked)
>> compressed data will attack the end system, such as: buffer overflow
>> and resource consumption! Some of the concerns are covered in the
>> "Security Considerations" section.
> This list of security concerns doesn't cover a popular recent abuse of
> compression algorithms, which is an attacker getting to repeatedly mix
> arbitrary (attacker-supplied) data with secret data (passwords, cookies)
> that gets sent over an encrypted channel.  An attacker who can do this
> and observe the length of the ciphertext can potentially reconstruct the
> secret data.
>
> See for example:
>
>   https://en.wikipedia.org/wiki/CRIME
>
> If this compression algorithm is resistant to this attack (which i
> doubt), it should be stated so in the draft.  If it is not resistant to
> the attack, then the draft should at least make note of the issue and
> pointedly suggest that applications compressing sensitive data before
> encrypted transport MUST NOT mix sensitive data with non-sensitive
> (potentially-attacker-supplied) data in the same compression stream.  Or
> would separating sensitve/non-sensitive data in one stream into distinct
> meta-blocks be sufficient?  i don't understand the encryption scheme
> well enough to know.  Either way, the authors of the draft are likely in
> the best position to make that clear.
>
> Regards,
>
>      --dkg
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview