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

Barry Leiba <> Wed, 05 October 2016 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2244F129474; Wed, 5 Oct 2016 13:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wodiDjGVkwe6; Wed, 5 Oct 2016 13:52:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DF7A129470; Wed, 5 Oct 2016 13:52:45 -0700 (PDT)
Received: by with SMTP id n189so156488360qke.0; Wed, 05 Oct 2016 13:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=oih2TvV/cLfe86rrD/3HxWuMYQdrFreRvZNnZ/EXJRQ=; b=njVmRb+V0JA6B2MTMsz/mRiq9pHaChN3vkr3OgKAFQg1f0ZJxdwX/uR0vCkdykS7QD wL/WUXLgtsgqiNjfDtdVKr6wR7OkgSQqEvS38+39yqmrYjw1gQce0xyI9dbX2SOvXhIN gqEWYRs57jEM25oFQB+0rYoQrOKSuBKFA1mNtVJwKwNCXMZ7qfU2VVz0cxLkjmEU3p0M M04cUfXQwQVqFcagV4oiw84NFlW2WoykhVDbE36YPymXZZAZI7WfFPmpaNExfw8BFH8i 5a2KQ0ATTHuNlM9t664aK5eYJVvzttfk9N/6mO6zec8ZlRsQsGfWs1MnYu4RO90fYJTK F6pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=oih2TvV/cLfe86rrD/3HxWuMYQdrFreRvZNnZ/EXJRQ=; b=EbZ80e2XKlkFfxEIuWwNFoBVK2/9B/UNfCb84u/cHm5wcasPgOfUoG5n8TRkXw/pv2 7RHOarQdRGT4V3eQgYttQbaLYJ+OYGcffHeDX0IkgWCZrrg0BYOXz/QzXW5O3nEonLqX aSMEoOK2FosX30enEqrVF1LiW9RPJCp01/9cHNhUps3Sw1e9Vdfk+/KLjrClohxPD2gY vtcwhjmzNTK1sp1TugikAhxD34qGfFy+HAOCLps5iPcBHhbdrFJIU0t3H36h5lVWhdAV 6HvxedJX85tr3aduwRpWMme5tT4EWtHm02RFUEALWS5sdAIbxqXI/W+aDGnzofsvV8Oi XAzQ==
X-Gm-Message-State: AA6/9RlP5uVCDh7g2HXYQx9tEZ11uqj4qRwIxmHWk6BbyY9bTlAbgBlbNgYHiDCu8P/iC7GCrZO8E4y3ojzSag==
X-Received: by with SMTP id p63mr10619834qka.277.1475700764342; Wed, 05 Oct 2016 13:52:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Oct 2016 13:52:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Barry Leiba <>
Date: Wed, 05 Oct 2016 16:52:43 -0400
X-Google-Sender-Auth: W4YZMeyGAQ834QzG-ITLQOVgCWg
Message-ID: <>
To: Julien ÉLIE <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 05 Oct 2016 20:52:47 -0000

I've been thinking on this since you mentioned it, and I have mixed
feelings.  So let me spread them out here:

On the one hand, it's well known that poorly implemented compression
has a lot of potential for problems of various kinds, including
security.  You're basically considering saying that, and saying that
it's therefore important to implement the algorithms correctly.  Well,

On the other hand, there *is* this particular issue that we know can
be a sticky point, so... why not mention it?  Kind of saying that you
have to implement the algorithms correctly, and that you should be
particularly careful about buffer sizes when deflating because just a
few bytes can deflate into unexpectedly huge results, and that's often
used to attempt attacks.

And on the third hand (I'm Martian), text is cheap, and if a few words
can be helpful, that seems reasonable.

On the fourth hand (and that's all that Martians have), it's not this
document's job to cover security (or other) issues in the compression
algorithms themselves.

So, yes: in the end, I think it's worth putting in a few words about
this, just to be clear that it's a common trap.


On Mon, Oct 3, 2016 at 4:47 PM, Julien ÉLIE <> wrote:
> 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 <>, "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.