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
- [secdir] secdir review of draft-alakuijala-brotli… Xialiang (Frank)
- Re: [secdir] secdir review of draft-alakuijala-br… Daniel Kahn Gillmor
- Re: [secdir] secdir review of draft-alakuijala-br… Tobias Gondrom
- Re: [secdir] secdir review of draft-alakuijala-br… Daniel Kahn Gillmor
- Re: [secdir] secdir review of draft-alakuijala-br… Tobias Gondrom
- Re: [secdir] secdir review of draft-alakuijala-br… Zoltan Szabadka
- [secdir] 答复: secdir review of draft-alakuijala-br… Xialiang (Frank)