[secdir] 答复: secdir review of draft-alakuijala-brotli-08

"Xialiang (Frank)" <frank.xialiang@huawei.com> Thu, 21 April 2016 02:06 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AED0A12DB2D; Wed, 20 Apr 2016 19:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LahTsBZQNclT; Wed, 20 Apr 2016 19:06:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E5912D9AA; Wed, 20 Apr 2016 19:06:34 -0700 (PDT)
Received: from (EHLO lhreml701-cah.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMV02210; Thu, 21 Apr 2016 02:06:32 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com ( by lhreml701-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Thu, 21 Apr 2016 03:06:31 +0100
Received: from SZXEMA502-MBS.china.huawei.com ([]) by szxema411-hub.china.huawei.com ([]) with mapi id 14.03.0235.001; Thu, 21 Apr 2016 10:06:27 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: Zoltan Szabadka <szabadka@google.com>
Thread-Topic: secdir review of draft-alakuijala-brotli-08
Thread-Index: AdGTthpEGuVvRaAtQJGDUJWf2eunBwG5tf0AADUIi8A=
Date: Thu, 21 Apr 2016 02:06:26 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AF2D953@SZXEMA502-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12AF2C416@SZXEMA502-MBS.china.huawei.com> <CAErD28-FydbU0mAXxQ3tphdVYz3t2yN_m-=MYTCnHOrm7++jyA@mail.gmail.com>
In-Reply-To: <CAErD28-FydbU0mAXxQ3tphdVYz3t2yN_m-=MYTCnHOrm7++jyA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AF2D953SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.571835A8.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ebc4f838632ed2123348c1a0477f6271
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/GGVYFvUV6CYVMpup9ANNn12fnXk>
Cc: "draft-alakuijala-brotli.all@tools.ietf.org" <draft-alakuijala-brotli.all@tools.ietf.org>, "aamelnikov@fastmail.fm" <aamelnikov@fastmail.fm>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, Nevil Brownlee <rfc-ise@rfc-editor.org>, "barryleiba@computer.org" <barryleiba@computer.org>
Subject: [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: Thu, 21 Apr 2016 02:06:41 -0000

Hi Zoltan,
Please see inline:

发件人: Zoltan Szabadka [mailto:szabadka@google.com]
发送时间: 2016年4月20日 16:38
收件人: Xialiang (Frank)
抄送: iesg@ietf.org; secdir@ietf.org; draft-alakuijala-brotli.all@tools.ietf.org; dkg@fifthhorseman.net; Nevil Brownlee; aamelnikov@fastmail.fm; barryleiba@computer.org
主题: Re: secdir review of draft-alakuijala-brotli-08

Thank you for reviewing the brotli internet draft.

We published a new version of the document (https://www.ietf.org/id/draft-alakuijala-brotli-09.txt) that addresses your comments on the "Security Considerations" section. This version also has a short paragraph about the CRIME attack.
[Frank]: Your improvement has addressed my issues, thank you.

We have not yet considered using brotli for IP compression. If my understanding is correct, it is not necessary to modify this document if we want to use brotli for IPComp later. According to the IANA considerations section of rfc 2407: "Requests for assignments of new IPCOMP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the IPCOMP framework". This suggests that we would have to write a separate rfc for this purpose with an IANA considerations section that updates the "IPSEC IPCOMP Transform Identifiers" registry.
[Frank]: So, what’s your idea?



On Mon, Apr 11, 2016 at 7:47 AM, Xialiang (Frank) <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>> wrote:


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

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.

The document appears in reasonably good shape.

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.

But there are still several security issues (TBDs) missing in the document that need to be addressed before publication.

Below is a series of my comments, questions for your consideration.

Discussion: Section 2

Right now, your compressed data format is mainly used for the http (see in the IANA section). Have you considered whether it can also be applied to IP compression?

Comments: Section 11

In the security considerations section, there are still some serious security issues not mentioned:

1. Resource consumption to the system containing a decompressor implementation: decompressing the invalid compressed data can make the decompressor system’s resource (cpu, memory, storage) to be consumed greatly, how to protect against this possible attack?

2. Resource consumption or buffer overflow to the system containing a compressor implementation: correspondingly, when a network proxy get some contents and need to compress them using this format, how to protect against the possible attacks when compressing the invalid (or faked) contents?

Thank you.