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

Julien ÉLIE <> Thu, 22 September 2016 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 358BC12B65C for <>; Thu, 22 Sep 2016 13:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e8PVOp4Jy2D7 for <>; Thu, 22 Sep 2016 13:59:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B2CEE12B5B5 for <>; Thu, 22 Sep 2016 13:59:52 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([]) by mwinf5d44 with ME id mksL1t00517Lgi403ksLLe; Thu, 22 Sep 2016 22:52:22 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Thu, 22 Sep 2016 22:52:22 +0200
To: Barry Leiba <>
References: <> <> <>
From: Julien ÉLIE <>
Organization: TrigoFACILE --
Message-ID: <>
Date: Thu, 22 Sep 2016 22:52:20 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc:, IESG <>, "" <>
Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05
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: Thu, 22 Sep 2016 20:59:57 -0000

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 <>, "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.

Julien ÉLIE

« Un voyage de mille lieues commence toujours par un premier pas. »
   (Lao Zi)