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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 11 April 2016 15:19 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EAF12F04C; Mon, 11 Apr 2016 08:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZhQOSr93ama; Mon, 11 Apr 2016 08:19:37 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB612F04B; Mon, 11 Apr 2016 08:19:37 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 53F35F991; Mon, 11 Apr 2016 11:19:35 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id F2E7E20143; Mon, 11 Apr 2016 11:19:34 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Xialiang (Frank)" <frank.xialiang@huawei.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-alakuijala-brotli.all@tools.ietf.org" <draft-alakuijala-brotli.all@tools.ietf.org>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F12AF2C416@SZXEMA502-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12AF2C416@SZXEMA502-MBS.china.huawei.com>
User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Mon, 11 Apr 2016 11:19:34 -0400
Message-ID: <87bn5guq9l.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/h1vDjPlyxqUPdf1PsiDaZQmhX58>
Subject: Re: [secdir] secdir review of draft-alakuijala-brotli-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2016 15:19:39 -0000

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