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

Matthew Lepinski <> Mon, 26 January 2015 21:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6D2691AD1DB; Mon, 26 Jan 2015 13:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iw4l-lE9tNPJ; Mon, 26 Jan 2015 13:05:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DB7E1A1B20; Mon, 26 Jan 2015 13:05:32 -0800 (PST)
Received: by with SMTP id x69so9256013oia.10; Mon, 26 Jan 2015 13:05:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nr23dQODn7tQO6ZOzUM9U8T7sNrXRHZcWQO9rjdIu6w=; b=uDl3VEuevkp0zBm1KrVgC6B7LPII9HZumKEQNrBl7w6tSwxvY3JGDwJaY9/I0chFwU m8p6Ru8tbsfg1MpbevNeX4ieR4KJf02Yk5DHXgApKH5TDltMuLLc6Uu4Ewkjj/aYyCnX Ift6FlYQyFWIoBVmGSzpJmRg1dGwSvKy4jLgt4BEpRWcV4k1x/fZcobJvil7hgZhbvjQ iWKbZ6zhrQa0x6X9bjkXZyHO2M+TQuektafO3rAKl6G8RSw5MSyg38By2lSnpViW8iOc rY+4QdSsManasvAS09iU7nYRDeAkGcMC5K8yPGharKuW0nxlvVVJZqrgnUsjg3zASFsc W9XA==
MIME-Version: 1.0
X-Received: by with SMTP id w17mr13817351obg.14.1422306330814; Mon, 26 Jan 2015 13:05:30 -0800 (PST)
Received: by with HTTP; Mon, 26 Jan 2015 13:05:30 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 26 Jan 2015 16:05:30 -0500
Message-ID: <>
From: Matthew Lepinski <>
To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= <>
Content-Type: multipart/alternative; boundary=001a113345c69c2d27050d947fb9
Archived-At: <>
Cc:, "" <>, "" <>
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 21:06:02 -0000

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

> 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:
>  ==========================
> Hervé.