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

Julien ÉLIE <julien@trigofacile.com> Mon, 03 October 2016 20:54 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 62AC5129549 for <secdir@ietfa.amsl.com>; Mon, 3 Oct 2016 13:54:55 -0700 (PDT)
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=unavailable 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 9oIL8AMN4WyC for <secdir@ietfa.amsl.com>; Mon, 3 Oct 2016 13:54:54 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by ietfa.amsl.com (Postfix) with ESMTP id AE27D129557 for <secdir@ietf.org>; Mon, 3 Oct 2016 13:54:53 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d09 with ME id r8nN1t00D17Lgi4038nNHv; Mon, 03 Oct 2016 22:47:22 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Mon, 03 Oct 2016 22:47:22 +0200
X-ME-IP: 92.170.5.52
To: Barry Leiba <barryleiba@computer.org>
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>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <1b5edd03-675c-01b7-6d06-c2e155987929@trigofacile.com>
Date: Mon, 03 Oct 2016 22:47:22 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <bf55ee7b-13ae-a162-ceb7-57ccedac1d35@trigofacile.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jvxoqa9yH0hdYYzGdj4dDY8CM2Y>
Cc: draft-murchison-nntp-compress.all@ietf.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: Mon, 03 Oct 2016 20:54:55 -0000

Hi Barry,

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?)

Thanks,

-- 
Julien

Le 22/09/2016 à 22:52, Julien ÉLIE a écrit :
> Hi Barry,
>
> Thanks for your answer.  I'll have a deeper look at it soon.
>
> As for the remaining "small points" of rewording (SHOULD, MUST, etc.),
> I'll calmly see them when updating the draft after Last Call.  In case I
> have a doubt for the best wording, I'll ask Ken (co-author) and Michael
> (write-up shepherd) their preference.  We'll obviously manage to come up
> with the "final" rewording as we'll have 3 votes for 2 choices.
>
>
> Now that I think about it, wouldn't it be worth adding something about
> possible "out of memory" attacks in the Security Considerations Section?
>
> According to <http://zlib.net/zlib_tech.html>, "a 50MB file filled with
> zeros [...] a version of run-length encoding optimized for this sort of
> unusual data file [...] could encode the test file in five bytes. That
> would be a compression factor of 10,000,000:1".
> So sending just 5 bytes may require an expansion to 50MB.
>
> Implementations therefore really need to check that the uncompressed
> data does not exceed an upper bound limit.
>
> RFC 1951 (DEFLATE) does not mention it in its Security Considerations,
> and I don't remember having seen that in other RFCs too.  Maybe we
> should say a word for it in the NNTP COMPRESS extension.
>