Return-Path: 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 9EAB212E1FD for ; Wed, 20 Apr 2016 01:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 FDLt5rIoRrNC for ; Wed, 20 Apr 2016 01:38:28 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414A912E2A0 for ; Wed, 20 Apr 2016 01:38:27 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id j11so36452260lfb.1 for ; Wed, 20 Apr 2016 01:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sefB4Dfkrc7maQF7jWL6LxzCcIsYFaycnPS/TLRc2cU=; b=cukBdlSmAiJMJxbvPzcUZJ3+YDsn3FtDSekGQpEIXLOC8UzlMMiKYnK5904436d28n 0RXc/PQc4fmhLPhNHtRf/r0KiECTeWUQUL0TiRIuraNTHFDYfHRHfBDAJJw2E6strGjY +755aSbn5H+ubIY99nC0XmQp2/c01/01PJTiiK81lTeAGql15v30o5i15yWvDAf2APjn OHdhXqDDjVMjHmxkPjFjCaW/51he3gGFTN58mnPwSm7yhqblToLFOSw36KytSXRvirx3 IVFblwHPI9wZdn4fFyPrBCFr6WYfGtyPQb6KEvwWJw8kMObw8bBy8GScCb3kYUqwhJpI Nf2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sefB4Dfkrc7maQF7jWL6LxzCcIsYFaycnPS/TLRc2cU=; b=MonFH9ETa8maVzKBJfkNtvvnPkRQJ+oQBhPT1vi2cGXcJrn48Cc1oHddr8zEzx2/ZO jkFAER0VRk8VgRNn7Eo+XmjZLTnRgMs4+Hvc0eluwEBt6SwdGP8nfFqM3GCAz8JeKvFl qvcu3CWYdMHweK8esVDvBZnvzTcXGoz6BMlk7ARcgtCnP6IdsS8XXRZAWycPOmBNxSVh zOVWz0gRGYMBWxbemiSfMlOJIerLT08nCCedcoXAHwbuf4PWheNX4iNtRWTqkFGXQ23V a37DIhwJbXPCW8T3MimUIqnQLQrzi8y5ouOnF/j/03WbxV+qk6OntZMrdCB/c5/eUxk1 Y6Vg== X-Gm-Message-State: AOPr4FXxWqrM8Qjbn+3uX+JjwE0Yi3I0sZ9G7DE1NVHfaTJGplx8ixhzmR/hAcKV0jfgCRMV1xjNGk+BjmU/cSrr MIME-Version: 1.0 X-Received: by 10.25.85.210 with SMTP id j201mr2690888lfb.132.1461141505224; Wed, 20 Apr 2016 01:38:25 -0700 (PDT) Received: by 10.112.60.74 with HTTP; Wed, 20 Apr 2016 01:38:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2016 10:38:24 +0200 Message-ID: From: Zoltan Szabadka To: "Xialiang (Frank)" Content-Type: multipart/alternative; boundary=001a1141d826631cc70530e68448 Archived-At: Cc: "draft-alakuijala-brotli.all@tools.ietf.org" , aamelnikov@fastmail.fm, "secdir@ietf.org" , "iesg@ietf.org" , Nevil Brownlee , barryleiba@computer.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:38:30 -0000 --001a1141d826631cc70530e68448 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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. Thanks, Zoltan On Mon, Apr 11, 2016 at 7:47 AM, Xialiang (Frank) wrote: > Hello, > > > > > > 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 are= a > directors. Document editors and WG chairs should treat these comments ju= st > 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 =E2=80=9CSecurity Considerations= =E2=80=9D section. > > > > But there are still several security issues (TBDs) missing in the documen= t > 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 i= n > 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=E2=80=99s resource (cpu, memory, storage) to be consu= med > 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. > > > > B.R. > > Frank > > > --001a1141d826631cc70530e68448 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for reviewing the brotli internet draft.
We published a new version of the document (https://www.ietf.org/id/dra= ft-alakuijala-brotli-09.txt) that addresses your comments on the "= Security Considerations" section. This version also has a short paragr= aph about the CRIME attack.

We have not yet consid= ered 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:=C2=A0"= ;Requests for assignments of new IPCOMP transform identifiers must be accom= panied 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.

Thanks,
Zoltan

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

Hello,

=C2=A0

=C2=A0

I have reviewed this document as part of the securi= ty directorate's ongoing effort to review all IETF documents being proc= essed by the IESG.=C2=A0 These comments were written primarily for the bene= fit of the security area directors.=C2=A0 Document editors and WG chairs should treat these comment= s just like any other last call comments.

=C2=A0

=C2=A0

This document defines a lossless compressed data fo= rmat that compresses data using a combination of the LZ77 algorithm and Huf= fman coding, with efficiency comparable to the best currently available gen= eral-purpose compression methods.

=C2=A0

=C2=A0

The document appears in reasonably good shape.

=C2=A0

In general, this document specify a new compressed = data format which is used in the end points of a connection, which is not d= irectly 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 secu= rity concern is about how the bad (or faked) compressed data will attack th= e end system, such as: buffer overflow and resource consumption! Some of the concerns are covered in the <= span lang=3D"EN-US" style=3D"font-family:"Courier New"">=E2=80=9C= Security Considerations=E2=80=9D section.

=C2=A0

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

=C2=A0

=C2=A0

Below is a series of my comments, questions for you= r consideration.

=C2=A0

=C2=A0

Discussion: Section 2

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

=C2=A0

=C2=A0

=C2=A0

Comments: Section 11

In the security considerations section, there are s= till 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=E2=80=99s resource (cpu, memory, storage) to be consumed greatly, how to protect aga= inst this possible attack?

2. Resource consumption or buffer overflow to the s= ystem containing a compressor implementation: correspondingly, when a netwo= rk 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?<= /u>

=C2=A0

=C2=A0

=C2=A0

Thank you.

=C2=A0

B.R.=

Frank

=C2=A0


--001a1141d826631cc70530e68448--