Re: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-10

[Matthew Lepinski <[e-mail]>]

Thanks a lot.

706 looks good. It is a small change, but I think it will be helpful.

On Mon, Jan 26, 2015 at 11:54 AM, Hervé Ruellan <[e-mail]>
wrote:

> Hi Matthew,
>
>
> On 01/19/2015 04:46 AM, Matthew Lepinski wrote:
>
>> 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 with the intent of improving security
>> requirements and considerations in IETF drafts.  Comments not addressed
>> in last call may be included in AD reviews during the IESG review.
>> Document editors and WG chairs should treat these comments just like any
>> other last call comments.
>>
>> This document specifies HPACK, the compression scheme used by HTTP/2. A
>> new compression scheme was needed for HTTP/2 because of attacks against
>> systems where traditional compression schemes were used to compress HTTP
>> headers sent over an encrypted TLS connection. (e.g., the CRIME attack
>> against SPDY.) HPACK is specifically designed to avoid CRIME and similar
>> attacks.
>>
>> I believe that this document is mature and nearly ready for publication.
>> However, I have one concern and would request a change to the document
>> (see below).
>>
>> After reviewing this document and looking at the PETAL paper it
>> references, I am satisfied that -- as the authors claim -- the HPACK
>> scheme [when used to compress HTTP headers] is secure relative to our
>> (the security community) current understanding of attacks against
>> encryption of compressed data. That is, I believe that the authors have
>> adequately addressed -- in the design of HPACK and the associated
>> Security Considerations section -- all known security issues.
>>
>> That being said, since HPACK is a relatively new algorithm, and since
>> encryption of compressed headers is known to be somewhat perilous, it is
>> possible that a clever attacker will develop a new attack in the future
>> (i.e., CRIME++ ) that works against HPACK-compressed header fields. I
>> haven't read the latest version of HTTP/2 carefully enough to know
>> whether HTTP/2 has a mechanism for an implementation to turn off use of
>> HPACK if such an attack is discovered. However, planning for a possible
>> future attack against HPACK would probably be wise.
>>
>
> While it's not possible to turn off use of HPACK from HTTP/2, it is
> possible to not use any indexing into HPACK resulting in encoding all
> values as literals. This is the fallback if ever HPACK is compromised.
>
>  ==========================
>> REQUEST FOR CHANGE TO: draft-ietf-httpbis-header-compression
>>
>> The Security Considerations in this document are extremely well-written
>> (particularly Sections 7.1.1 and 7.1.2). Based on experience with the
>> CRIME attack, there are significant security concerns (described in
>> Section 7.1) with encrypting compressed headers. Section 7.1.1 explains
>> how these concerns relate to HPACK and Section 7.1.2 describes steps
>> that an HPACK encoder implementation can take to mitigate these
>> concerns. These sections are very important -- indeed, more important
>> than the security considerations sections for many IETF documents.
>>
>> I would very much like to see a forward reference to Section 7.1.2 (or
>> perhaps just Section 7.1 as whole) at some point earlier in the document
>>   when the authors are describing the encoder (probably somewhere in
>> Section 2). That is, there are important mitigation techniques that an
>> implementer should have in mind when creating an HPACK encoder. I
>> believe that referencing these techniques when the encoding process is
>> described would be a good idea.
>>
>
> I added pointers to the security sections in:
> https://github.com/http2/http2-spec/pull/706
>
>  ==========================
>>
>
> Hervé.
>