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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Nov 2016 17:25:48 +0000

Hi Julien,

Sorry for the late followup on this.

On 03/10/2016 21:47, 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?)

I think this would be a good idea.

Best Regards,
Alexey

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 22 Nov 2016 21:46:31 +0100

Hi Alexey,

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