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

Hervé Ruellan <> Mon, 26 January 2015 16:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CAEF81ACCDE; Mon, 26 Jan 2015 08:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.26
X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aSjeimofCWim; Mon, 26 Jan 2015 08:54:19 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FA6F1ACCE4; Mon, 26 Jan 2015 08:54:18 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id t0QGsG6s028686; Mon, 26 Jan 2015 17:54:16 +0100
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id t0QGsGA7017638; Mon, 26 Jan 2015 17:54:16 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 26 Jan 2015 17:54:14 +0100
Message-ID: <>
Date: Mon, 26 Jan 2015 17:54:14 +0100
From: =?UTF-8?B?SGVydsOpIFJ1ZWxsYW4=?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Matthew Lepinski <>, "" <>, "" <>, <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
X-Mailman-Approved-At: Tue, 27 Jan 2015 08:18:40 -0800
Subject: Re: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jan 2015 16:54:21 -0000

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:

> ==========================