Last Call Review of draft-alakuijala-brotli-08
review-alakuijala-brotli-08-secdir-lc-xia-2016-04-14-00

Hello,





I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
 directors.  Document editors and WG chairs should treat these comments just
 like any other last call comments.





This document defines a lossless compressed data format that compresses data
using a combination of the LZ77 algorithm and Huffman coding, with efficiency
comparable to the best currently available general-purpose
 compression methods.





The document appears in reasonably good shape.



In general, this document specify a new compressed data format which is used in
the end points of a connection, which is not directly subject to network
security issues. In other words, the compressed contents can
 be protected by all the existing security technologies (i.e., encryption,
 authentication/authorization, anti-attack, etc) if necessary. The main
 security concern is about how the bad (or faked) compressed data will attack
 the end system, such as: buffer overflow and resource consumption! Some of the
 concerns are covered in the

“

Security Considerations

”

 section.



But there are still several security issues (TBDs) missing in the document that
need to be addressed before publication.





Below is a series of my comments, questions for your consideration.





Discussion: Section 2

Right now, your compressed data format is mainly used for the http (see in the
IANA section). Have you considered whether it can also be applied to IP
compression?







Comments: Section 11

In the security considerations section, there are still some serious security
issues not mentioned:

1. Resource consumption to the system containing a decompressor implementation:
decompressing the invalid compressed data can make the decompressor system

’

s
 resource (cpu, memory, storage) to be consumed greatly, how to protect against
 this possible attack?

2. Resource consumption or buffer overflow to the system containing a
compressor implementation: correspondingly, when a network proxy get some
contents and need to compress them using this format, how to protect against
 the possible attacks when compressing the invalid (or faked) contents?







Thank you.



B.R.

Frank