Subject: [secdir] secdir review of draft-alakuijala-brotli-08

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 11 Apr 2016 05:47:40 +0000

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 11 Apr 2016 11:19:34 -0400

On Mon 2016-04-11 01:47:40 -0400, "Xialiang (Frank)" <[email-masked]> wrote:
> 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.
 [...]
> 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.

This list of security concerns doesn't cover a popular recent abuse of
compression algorithms, which is an attacker getting to repeatedly mix
arbitrary (attacker-supplied) data with secret data (passwords, cookies)
that gets sent over an encrypted channel.  An attacker who can do this
and observe the length of the ciphertext can potentially reconstruct the
secret data.

See for example:

 https://en.wikipedia.org/wiki/CRIME

If this compression algorithm is resistant to this attack (which i
doubt), it should be stated so in the draft.  If it is not resistant to
the attack, then the draft should at least make note of the issue and
pointedly suggest that applications compressing sensitive data before
encrypted transport MUST NOT mix sensitive data with non-sensitive
(potentially-attacker-supplied) data in the same compression stream.  Or
would separating sensitve/non-sensitive data in one stream into distinct
meta-blocks be sufficient?  i don't understand the encryption scheme
well enough to know.  Either way, the authors of the draft are likely in
the best position to make that clear.

Regards,

    --dkg

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 12 Apr 2016 18:16:13 +0200

Dear Daniel,
in my understanding this ID is _only_ about a compression, not about 
encryption.
Therefore it is not even intended to be resistant to the attack you 
describe below.
(for proper confidentiality the channel would need to be encrypted.)
Best regards, Tobias

On 11/04/16 17:19, Daniel Kahn Gillmor wrote:
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 Apr 2016 12:56:32 -0400

On Tue 2016-04-12 12:16:13 -0400, Tobias Gondrom <[email-masked]> wrote:
> encryption.  Therefore it is not even intended to be resistant to the
> attack you describe below.  (for proper confidentiality the channel
> would need to be encrypted.)

Agreed, but encryption specs are often _only_ about encryption, even
though they're sometimes layered over a compression protocol.

I think your argument implies that this warning doesn't belong in either
Security Considerations section (of the compression-less encryption
protocol, or of the encryption-less compression protocol), which makes
me sad.

Instead, i think we should make people considering either protocol aware
of the risks of the combination.  This doesn't have to be a huge edit,
just a short paragraph in the security considerations.

     --dkg

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 14 Apr 2016 14:26:18 +0200

> just a short paragraph in the security considerations.

Just to be clear: This is just my own humble opinion, just one among 
many in the community. ;-)
It is up to the WG and editors to decide.

Cheers, Tobias

---

From: Zoltan Szabadka <[email-masked]>
Date: Wed, 20 Apr 2016 10:38:24 +0200

Thank you for reviewing the brotli internet draft.

We published a new version of the document (
https://www.ietf.org/id/draft-alakuijala-brotli-09.txt) that addresses your
comments on the "Security Considerations" section. This version also has a
short paragraph about the CRIME attack.

We have not yet considered using brotli for IP compression. If my
understanding is correct, it is not necessary to modify this document if we
want to use brotli for IPComp later. According to the IANA considerations
section of rfc 2407: "Requests for assignments of new IPCOMP transform
identifiers must be accompanied by an RFC which describes how to use the
algorithm within the IPCOMP framework". This suggests that we would have to
write a separate rfc for this purpose with an IANA considerations section
that updates the "IPSEC IPCOMP Transform Identifiers" registry.

Thanks,
Zoltan

On Mon, Apr 11, 2016 at 7:47 AM, Xialiang (Frank) <[email-masked]
> wrote:

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

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 21 Apr 2016 02:06:26 +0000

Hi Zoltan,
Please see inline:

发件人: Zoltan Szabadka [mailto:[email-masked]]
发送时间: 2016年4月20日 16:38
收件人: Xialiang (Frank)
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Nevil Brownlee; [email-masked]; [email-masked]
主题: Re: secdir review of draft-alakuijala-brotli-08

We published a new version of the document (https://www.ietf.org/id/draft-alakuijala-brotli-09.txt) that addresses your comments on the "Security Considerations" section. This version also has a short paragraph about the CRIME attack.
[Frank]: Your improvement has addressed my issues, thank you.

We have not yet considered using brotli for IP compression. If my understanding is correct, it is not necessary to modify this document if we want to use brotli for IPComp later. According to the IANA considerations section of rfc 2407: "Requests for assignments of new IPCOMP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the IPCOMP framework". This suggests that we would have to write a separate rfc for this purpose with an IANA considerations section that updates the "IPSEC IPCOMP Transform Identifiers" registry.
[Frank]: So, what’s your idea?

B.R.
Frank

Thanks,
Zoltan

On Mon, Apr 11, 2016 at 7:47 AM, Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

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.

Discussion: Section 2

Comments: Section 11

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?

Thank you.

B.R.

Frank