Re: [secdir] Secdir review of draft-murchison-nntp-compress-05

Julien ÉLIE <julien@trigofacile.com> Tue, 22 November 2016 20:46 UTC

Return-Path: <julien@trigofacile.com>
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 3EF4F129B72 for <secdir@ietfa.amsl.com>; Tue, 22 Nov 2016 12:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] 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 mMTwGsp4l7Du for <secdir@ietfa.amsl.com>; Tue, 22 Nov 2016 12:46:40 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CC712944B for <secdir@ietf.org>; Tue, 22 Nov 2016 12:46:39 -0800 (PST)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d88 with ME id B8mX1u00B17Lgi4038mX2x; Tue, 22 Nov 2016 21:46:37 +0100
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Tue, 22 Nov 2016 21:46:37 +0100
X-ME-IP: 92.170.5.52
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <CALaySJ+mJdorTkygsZ==Bja+0ZmavTkq2kC33QJ67LeM34K=Ng@mail.gmail.com> <20981db3190142193043f1445abadaa3@trigofacile.com> <CALaySJKP3AEgb7=rRz=T0R4vKWOHE6AAHeg-k-h28KrtjXP64A@mail.gmail.com> <bf55ee7b-13ae-a162-ceb7-57ccedac1d35@trigofacile.com> <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com> <fa6925d7-ed59-fa47-c4c0-14f514492f53@isode.com>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <a606249d-f116-24c0-6470-86274c4b1242@trigofacile.com>
Date: Tue, 22 Nov 2016 21:46:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <fa6925d7-ed59-fa47-c4c0-14f514492f53@isode.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/xrG3BmV-h6NjzsfONFxt0x0kqfQ>
Cc: draft-murchison-nntp-compress.all@ietf.org, Barry Leiba <barryleiba@computer.org>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05
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: Tue, 22 Nov 2016 20:46:42 -0000

Hi Alexey,

>> I'm currently reviewing the comments I need to take into account for
>> the document.
>> Do you believe I should add a note about a possible security issue as
>> far as the use of DEFLATE is concerned?  (see below)
>> (An "out of memory" attack?)
>
> I think this would be a good idea.

I took it into account in the -06 version.
Paragraph added at the end of Section 7 (Security Considerations):

    Last but not least, careful consideration should be given to
    protections against implementation errors that introduce security
    risks with regards to compression algorithms.  See for instance the
    part of Section 6 of [RFC3749] about compression algorithms that can
    occasionally expand, rather than compress, input data.



It covers security issues related to compression.  Section 6 of RFC3749 
is as follows:

    Compression algorithms tend to be mathematically complex and prone to
    implementation errors.  An implementation error that can produce a
    buffer overrun introduces a potential security risk for programming
    languages and operating systems that do not provide buffer overrun
    protections.  Careful consideration should thus be given to
    protections against implementation errors that introduce security
    risks.

    As described in Section 2, compression algorithms can occasionally
    expand, rather than compress, input data.  This feature introduces
    the ability to construct rogue data that expands to some enormous
    size when compressed or decompressed.  RFC 2246 describes several
    methods to ameliorate this kind of attack.  First, compression has to
    be lossless.  Second, a limit (1,024 bytes) is placed on the amount
    of allowable compression content length increase.  Finally, a limit
    (2^14 bytes) is placed on the total content length.  See section
    6.2.2 of RFC 2246 [2] for complete details.

-- 
Julien ÉLIE

« Ce que j'aime chez vous, c'est que vous savez jusqu'où on va trop
   loin. » (Cocteau)